Bug#985320: mariadb-common: Spurious messages when installing package
Package: mariadb-common Version: 1:10.5.9-1 Severity: minor Dear Maintainer, When upgrading python3-mysqldb apt also update mariadb-common and I get some spurious messages : Setting up mariadb-common (1:10.5.9-1) ... update-alternatives: using /etc/mysql/mariadb.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode update-alternatives: warning: not replacing /etc/mysql/my.cnf with a link I didn't have MariaDB installed (i am running mysql 5.7.33). Regards JP P -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=C Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-common depends on: ii mysql-common 5.8+1.0.7 mariadb-common recommends no packages. mariadb-common suggests no packages.
Bug#985245: src:ppmd: reintroduced with lower version number, different project?
alright, i've uploaded src:python-ppmd right now, which is just a rename of the src:ppmd package. Sean, do you need me to file a RM for src:ppmd or will dak automagically take care of it? Regards, Sandro On Sun, Mar 14, 2021 at 9:51 PM Paul Wise wrote: > > On Sun, 2021-03-14 at 21:44 -0400, Sandro Tosi wrote: > > > but other paragraphs do (i think) :) > > Ah, I see! > > > there's no guarantee (althought i find it highly unlikely) that > > src:ppmd will not reach the same version of the old ppmd that used to > > be present in the archive a decade ago. > > The requirement is easy to workaround though, by appending extra chars > to the affected versions, but that means remembering the requirement. > Of course just renaming the source package is a much simpler fix. > > I think just uploading src:python-ppmd will fix this since src:ppmd > will get autoremoved by the dak decrufting since src:python-ppmd will > take over the binary packages of src:ppmd with newer versions. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#985052: python-sympy-doc: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/python-sympy-doc/sympy-live.sh
Control: tags -1 + patch https://salsa.debian.org/science-team/sympy/-/merge_requests/2 -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#979296: u-boot: Restructure the packaging
On 2021-03-13, Nicolas Boulenguez wrote: > The suggested style changes do not make sense in unstable during the > freeze, but may in experimental. > The diffs attached to intermediate steps > 980236 980360 980362 980359 980358 980361 980363 > apply to 2021.04-rc3+dfsg-1. I just applied each of the above patches from each of those bugs against salsa/master... > The attached rebased diffs then apply on the result. > The changes are tightly connected, but order matters because they > modify the same parts. Indeed... > From cfd86d808db372dff154ca6b163edbf67ec38e6d Mon Sep 17 00:00:00 2001 > From: Nicolas Boulenguez > Date: Sat, 9 Jan 2021 15:40:19 +0100 > Subject: [PATCH 3/4] Replace many shell constructs with Make constructs > > so that each actually executed command is visible in logs, and errors > are reported immediately. > > Delegate selection of host packages to dh_listpackages, and allow the > caller to build any combination of .debs and platforms by setting Make > variables on the command line. For example, > DEB_BUILD_PROFILES=pkg.uboot.subarch.foo debian/rules build > is equivalent to > debian/rules build built_subarchs=u-boot-foo. > --- > debian/bin/update-substvars| 12 --- > debian/rules | 146 +++-- > debian/targets.mk | 43 ++ > debian/u-boot-rockchip.install | 7 +- > 4 files changed, 112 insertions(+), 96 deletions(-) > delete mode 100755 debian/bin/update-substvars > mode change 100755 => 100644 debian/u-boot-rockchip.install I can't get this to apply against -rc3 or -rc4 (just updated in u-boot/master). These changes are complex enough, it would be preferable to create a merge request on salsa. Thanks for all your work on this! live well, vagrant signature.asc Description: PGP signature
Bug#985252: vorta: clicking on the notification bar icon doesnt open the application
Sandro Tosi writes: >> I was unable to reproduce this on either my sid system or my buster >> system (with local bpo of 0.7.5); both systems use KDE, and left >> clicking on the tray icon opens the application window in both cases. > > i'm using gnome-flashback here > >> Would you please share what desktop environment, > > gnome with the flashback session > >> and possibly system >> tray application you're using? > > not even sure how to get that information, i guess gnome default one > Thanks for this info :-) I've also just confirmed that left click on Vorta's tray applet doesn't function correctly using tint2 on openbox. >> I vaguely remember this might be the >> case under GNOME Shell (I forget which system tray extension). Would >> you please also check if system-tray-using applications like >> transmission-qt are affected, > > i tried transmission-qt, and a single left click on a > minimized-to-tray app opens the app again, as expected > Cool, so Qt tray applets on gnome-flashback (and presumably GNOME shell) are good. That's a relief! (qjackctl would have also been affected). >> and ideally also another PyQt >> system-tray-using application? > > anyone you can suggest here? > It was more difficult than expected to track one down, and I wasn't able to find one in Debian, but this one looks decent for the purposes of testing (PyQt5, with a left-click action) https://pypi.org/project/weather-applet/ It introduces an additional factor (appletlib); however, if weather-applet with appletlib functions correctly on gnome-flashback, then I think it will be reasonable to suppose that appletlib has a more correct system-tray implementation than Vorta; Then we can forward both this bug and a link to the GPL3+ appletlib library to Manu, as a PyQt5 tray reference implementation--given that appletlib and this bug exist, I suspect system-tray support might not be as straight-forward to implement as the PyQt5 docs indicate. >> I think you'll agree that we ought to >> verify that this isn't a more widespread Qt, PyQt, GNOME Shell, or >> system-tray-extension issue :-) > > no problem in further debugging this issue as instructed > Thanks again for taking the time to debug this; now we've narrowed it down to either a Vorta issue, or a PyQt5 issue which appears to only affect Vorta--since it doesn't seem like anything else in the archive uses this functionality. Cheers, Nicholas signature.asc Description: PGP signature
Bug#985329: courier-mta not startable/configurable due mkesmtpdcert
Package: courier-mta Version: 1.0.16-3 Severity: grave Justification: renders package unusable i guess real reason of bug #984696 and #984694 is that the mkesmtpdcert tool has an error: check this sequence: it seems that the script put the pem file in the /usr/lib/courier event in /etc/courier, or maybe permission problems serveruno:/etc/courier# mkesmtpdcert /etc/courier/esmtpd.pem already exists. serveruno:/etc/courier# rm /etc/courier/emstpd.pem rm: no se puede borrar '/etc/courier/emstpd.pem': No existe el fichero o el directorio serveruno:/etc/courier# Markus.. the problem is not the smtpaccess.dat or imapaccess.dat so please check this again .. just run the script .. if you could reproduce it.. mark #984696 and #984694 as real solved i m still coding at the scripts but i just testing first upgrade xperience.. (i never do upgrade .. just one install and 9 years of peace since squeeze) Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#985313: [python-policy] html file has wrong filename, all links in TOC are dead
Package: python3-dev Severity: minor Version: 3.9.2-2 Hi, Today I found that the latest version of the python-policy is not on the debian.org website (https://www.debian.org/doc/devel-manuals#policy). An older version was available instead. That was because the scripts building the webpage had to adapted, as a result of your conversion to sphinx and the move of the document into the -dev package. I did that today. It works fine so far again. However - now it comes to the point of this report - the html file has the wrong filename in your package. It is named /usr/share/doc/python3/python-policy.html That leads to the situation, that all links in the table of content on the left are dead, since they link to a file named index.html. Renaming the file from python-policy.html into index.html fixes this problem. (I have worked around this problem for the website, so the file is already named index.html there, but you want to have a working file in your package nevertheless, I guess.) So long Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#985252: vorta: clicking on the notification bar icon doesnt open the application
> I was unable to reproduce this on either my sid system or my buster > system (with local bpo of 0.7.5); both systems use KDE, and left > clicking on the tray icon opens the application window in both cases. i'm using gnome-flashback here > Would you please share what desktop environment, gnome with the flashback session > and possibly system > tray application you're using? not even sure how to get that information, i guess gnome default one > I vaguely remember this might be the > case under GNOME Shell (I forget which system tray extension). Would > you please also check if system-tray-using applications like > transmission-qt are affected, i tried transmission-qt, and a single left click on a minimized-to-tray app opens the app again, as expected > and ideally also another PyQt > system-tray-using application? anyone you can suggest here? > I think you'll agree that we ought to > verify that this isn't a more widespread Qt, PyQt, GNOME Shell, or > system-tray-extension issue :-) no problem in further debugging this issue as instructed -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#985255: Systemd initiates fsckd for no apparent reason
Am 16.03.2021 um 02:34 schrieb Michael Biebl: Apparently /dev/sdb2 is not attached during boot, but you have listed it in /etc/fstab. Therefore systemd is waiting for it. You probably want noauto or nofail here, but not defaults. Please also keep in mind, that the kernel provided names are not necessarily stable, so I would advice to *not* use /dev/sd* but instead UUID= or LABEL= in /etc/fstab.
Bug#985252: vorta: clicking on the notification bar icon doesnt open the application
> It introduces an additional factor (appletlib); however, if > weather-applet with appletlib functions correctly on gnome-flashback it does "work": it cant find any weather data, but when i left click one it "tries" to show "No data available", see attachment, but at least it does something. > then I think it will be reasonable to suppose that appletlib has a more > correct system-tray implementation than Vorta; Then we can forward both > this bug and a link to the GPL3+ appletlib library to Manu, as a PyQt5 > tray reference implementation--given that appletlib and this bug exist, > I suspect system-tray support might not be as straight-forward to > implement as the PyQt5 docs indicate. i think this is a bug in vorta -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#985320: [debian-mysql] Bug#985320: mariadb-common: Spurious messages when installing package
Hi, On Tue, Mar 16, 2021 at 12:23:53AM +0100, jpp wrote: > When upgrading python3-mysqldb apt also update mariadb-common and I get some > spurious messages : > Setting up mariadb-common (1:10.5.9-1) ... > update-alternatives: using /etc/mysql/mariadb.cnf to provide /etc/mysql/my.cnf > (my.cnf) in auto mode > update-alternatives: warning: not replacing /etc/mysql/my.cnf with a link I don't see how these messages are spurious. They're accurate and the warnings seem appropriate and helpful to me. > I didn't have MariaDB installed (i am running mysql 5.7.33). bullseye doesn't ship MySQL 5.7.33, and most MySQL protocol -speaking packages are linked with MariaDB. On Debian, the release team have chosen to exclude MySQL in stable releases, so you have no choice but to use MariaDB to fulfill those dependencies if you want to use packages like python3-mysqldb. I suggest this bug should be wontfixed, but I'll leave that decision to others. Robie signature.asc Description: PGP signature
Bug#985325: mmv: new upstream maintainer and release (2.0rc2)
Control: tag -1 + confirmed Hi pabs, Paul Wise wrote: > mmv has apparently moved to GitHub and 2.0rc2 was released: > >https://github.com/rrthomas/mmv/ Yep. We're aware of it since this posting by the new upstream maintainer on Friday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149873#20 I'm watching the above git repo since then. :-) Surely won't update it for Bullseye. But I might make an upload to experimental. > There is a discussion on Hacker News with the maintainer: > >https://news.ycombinator.com/item?id=26454265 Thanks, wasn't aware of this. Not much new information, though. The mentioned feature removal and the hint to renameutils comes from my comment in the above mentioned bug report. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#983684: mupdf: CVE-2021-3407
On Sun, 28 Feb 2021 13:33:23 +0100 Salvatore Bonaccorso wrote: CVE-2021-3407[0]: | A flaw was found in mupdf 1.18.0. Double free of object during | linearization may lead to memory corruption and other potential | consequences. See #983104 for a NMU RFS with the fix for buster.
Bug#896460: Please package ipywidgets 7
Hi, There's any news about this? IPytree need ipywidgets>=7.5.0 Cheers, Emmanuel
Bug#985322: pack_name.c: add a prototype for the function "pack_name()"
Source: nn Version: 6.7.3-14 Severity: normal Tags: patch Dear Maintainer, >From 1fd7e771bb3f3581a931a4a0e34a510441685be2 Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Tue, 16 Mar 2021 01:26:52 + >Subject: [PATCH] pack_name.c: add a prototype for the function "pack_name()" Signed-off-by: Bjarni Ingi Gislason --- pack_name.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/pack_name.c b/pack_name.c index e99963f..855c6fc 100644 --- a/pack_name.c +++ b/pack_name.c @@ -11,6 +11,8 @@ #include "config.h" #include "global.h" +int pack_name(char *, char *, int); + /* #define NAME_TEST *//* Never define this ! */ #defineSEP_DOT 0 /* . */ -- 2.30.2 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- debconf information excluded -- Bjarni I. Gislason
Bug#983366: linphone-desktop: Settings popup menu
Hello Dennis, > > 1- the settings pop menu appears 'detached' from the main app > > window; also, it uses a font and font size that are not the > > 'upstream' app font and size (fwiw); > > 2- it only works once: if you close and try to open the settingss > > popup again, it fails to do so, and displays the following message > > in the teminal where i launched linphone; > > (linphone:83987): Gdk-WARNING **: 23:13:05.180: Couldn't > > map as window 0x555cd9b47560 as popup because it doesn't have a > > parent > Searching for that error message leads me to believe that this is > probably a wayland issue. Does it work correctly under X? What > desktop environment are you using? GNOME desktop - 3.38-4 Yes, Wayland, no idea about X 'only' but, worth mentioning that that the upstream appimage works fine, I mean running under the (exact) same 'conditions'/desktop env > Having the output of > > sed -n '/[[:space:]]\/\(usr\|lib\).*[.]so.*/s@^[^/]\+/@/@p' \ > /proc/$(pidof linphone)/maps|sort|uniq See below, Thanks, David sed -n '/[[:space:]]\/\(usr\|lib\).*[.]so.*/s@^[^/]\+/@/@p' /proc/$(pidof linphone)/maps|sort|uniq /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so /usr/lib/x86_64-linux-gnu/dri/iris_dri.so /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so /usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/lib/x86_64-linux-gnu/libantlr3c-3.4.so.0.0.0 /usr/lib/x86_64-linux-gnu/libaom.so.2.0.2 /usr/lib/x86_64-linux-gnu/libaribb24.so.0.0.0 /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0.23609.1 /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0.0.0 /usr/lib/x86_64-linux-gnu/libatspi.so.0.0.1 /usr/lib/x86_64-linux-gnu/libavcodec.so.58.91.100 /usr/lib/x86_64-linux-gnu/libavutil.so.56.51.100 /usr/lib/x86_64-linux-gnu/libbctoolbox.so.1 /usr/lib/x86_64-linux-gnu/libbelcard.so.1 /usr/lib/x86_64-linux-gnu/libbellesip.so.1 /usr/lib/x86_64-linux-gnu/libbelr.so.1 /usr/lib/x86_64-linux-gnu/libblkid.so.1.1.0 /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1.0.9 /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1.0.9 /usr/lib/x86_64-linux-gnu/libbsd.so.0.11.3 /usr/lib/x86_64-linux-gnu/libbzrtp.so.0 /usr/lib/x86_64-linux-gnu/libc-2.31.so /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0 /usr/lib/x86_64-linux-gnu/libcodec2.so.0.9 /usr/lib/x86_64-linux-gnu/libcom_err.so.2.1 /usr/lib/x86_64-linux-gnu/libdatrie.so.1.4.0 /usr/lib/x86_64-linux-gnu/libdav1d.so.5.0.1 /usr/lib/x86_64-linux-gnu/libdbus-1.so.3.19.13 /usr/lib/x86_64-linux-gnu/libdeflate.so.0 /usr/lib/x86_64-linux-gnu/libdl-2.31.so /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.3.1 /usr/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1.0.0 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1.0.1 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 /usr/lib/x86_64-linux-gnu/libedit.so.2.0.63 /usr/lib/x86_64-linux-gnu/libelf-0.183.so /usr/lib/x86_64-linux-gnu/libepoxy.so.0.0.0 /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.12 /usr/lib/x86_64-linux-gnu/libfdk-aac.so.2.0.1 /usr/lib/x86_64-linux-gnu/libffi.so.7.1.0 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.3.0 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.17.4 /usr/lib/x86_64-linux-gnu/libfribidi.so.0.4.0 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8 /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2404.20 /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.4200.2 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6600.7 /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0 /usr/lib/x86_64-linux-gnu/libGLEW.so.2.1.0 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.7 /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0 /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6600.7 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.7 /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0 /usr/lib/x86_64-linux-gnu/libgpg-error.so.0.29.0 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.2.1 /usr/lib/x86_64-linux-gnu/libgsm.so.1.0.18 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.20 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.20704.0 /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0 /usr/lib/x86_64-linux-gnu/libicudata.so.67.1 /usr/lib/x86_64-linux-gnu/libicui18n.so.67.1 /usr/lib/x86_64-linux-gnu/libicuuc.so.67.1 /usr/lib/x86_64-linux-gnu/libilbc.so.3.0.4 /usr/lib/x86_64-linux-gnu/libjbig.so.0 /usr/lib/x86_64-linux-gnu/libjpeg.so.62.3.0 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1 /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.9 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
Bug#985324: unblock: solarwolf/1.5+dfsg1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ur...@debian.org, a...@debian.org Please unblock package solarwolf [ Reason ] The change fixes grave bug #984673 by replacing deprecated (and since python 3.9 removed) method isAlive() of threading.Thread with its successor is_alive(). [ Impact ] solarwolf currently fails to start in testing and will be autoremoved on April 04. [ Tests ] (manual) With the change can start and play the game, without not. [ Risks ] Change is trivial and the recommeded fix in the python 3.9 release notes [1] - "The isAlive() method of threading.Thread has been removed. It was deprecated since Python 3.8. Use is_alive() instead." [1] https://docs.python.org/3/whatsnew/3.9.html [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock solarwolf/1.5+dfsg1-3 diff -Nru solarwolf-1.5+dfsg1/debian/changelog solarwolf-1.5+dfsg1/debian/changelog --- solarwolf-1.5+dfsg1/debian/changelog 2020-03-23 06:22:20.0 +0700 +++ solarwolf-1.5+dfsg1/debian/changelog 2021-03-15 06:25:59.0 +0700 @@ -1,3 +1,11 @@ +solarwolf (1.5+dfsg1-3) unstable; urgency=medium + + * QA upload. + * Fix runtime error Thread object has no attribute isAlive. +Thanks to Judit Foglszinger for the patch. (Closes: #984673) + + -- Markus Koschany Mon, 15 Mar 2021 00:25:59 +0100 + solarwolf (1.5+dfsg1-2) unstable; urgency=medium * QA upload. diff -Nru solarwolf-1.5+dfsg1/debian/patches/replacing-isAlive-with-is_alive.patch solarwolf-1.5+dfsg1/debian/patches/replacing-isAlive-with-is_alive.patch --- solarwolf-1.5+dfsg1/debian/patches/replacing-isAlive-with-is_alive.patch 1970-01-01 07:00:00.0 +0700 +++ solarwolf-1.5+dfsg1/debian/patches/replacing-isAlive-with-is_alive.patch 2021-03-15 06:25:59.0 +0700 @@ -0,0 +1,33 @@ +Description: Replacing isAlive with is_alive + solarwolf fails to start because of an AttributeError: Thread object + has no attribute isAlive. The function was removed in Python 3.9. The patch + replaces it with the new one is_alive(). +--- +Bug-Debian: https://bugs.debian.org/984673 +Forwarded: no +Reviewed-By: Markus Koschany +Last-Update: 2021-03-12 + +--- solarwolf-1.5+dfsg1.orig/code/gameinit.py solarwolf-1.5+dfsg1/code/gameinit.py +@@ -161,7 +161,7 @@ class GameInit: + + now = pygame.time.get_ticks() + #we let the screen stay up for at about 1 second +-if not self.thread.isAlive(): ++if not self.thread.is_alive(): + if load_finished_status >= 0: + if now-self.starttime > 1200: + self.quit() +--- solarwolf-1.5+dfsg1.orig/code/gamenews.py solarwolf-1.5+dfsg1/code/gamenews.py +@@ -234,7 +234,7 @@ class GameNews: + self.clocks += 1 + self.cleartext() + +-if self.thread and (not self.thread.isAlive() and self.success): ++if self.thread and (not self.thread.is_alive() and self.success): + self.download_finished() + + clearme = None + diff -Nru solarwolf-1.5+dfsg1/debian/patches/series solarwolf-1.5+dfsg1/debian/patches/series --- solarwolf-1.5+dfsg1/debian/patches/series 2019-09-29 21:12:23.0 +0700 +++ solarwolf-1.5+dfsg1/debian/patches/series 2021-03-15 06:25:59.0 +0700 @@ -2,3 +2,4 @@ music.patch spelling.patch python3.patch +replacing-isAlive-with-is_alive.patch signature.asc Description: This is a digitally signed message part.
Bug#985325: mmv: new upstream maintainer and release (2.0rc2)
Package: mmv Version: 1.01b-19+b1 Severity: wishlist mmv has apparently moved to GitHub and 2.0rc2 was released: https://github.com/rrthomas/mmv/ There is a discussion on Hacker News with the maintainer: https://news.ycombinator.com/item?id=26454265 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#985329: solved upgrading to experimental
i have older packages yet in my install, i dont know how happened.. but do not close this bug until i found why happened after check and forces proper upgraded in xperimental.. is working Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#985327: printconf.c: remove a redeclared "*tmp_directory" and add a prototype for "print_config()"
Source: nn Version: 6.7.3-14 Severity: normal Tags: patch Dear Maintainer, >From 9b661c07514c3d20d200c8c15a88b987fc854c3c Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Tue, 16 Mar 2021 03:29:00 + >Subject: [PATCH] printconf.c: remove a redeclared "*tmp_directory" and > add a prototype for "print_config()" Signed-off-by: Bjarni Ingi Gislason --- printconf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/printconf.c b/printconf.c index 8a2c06f..65df8ea 100644 --- a/printconf.c +++ b/printconf.c @@ -7,6 +7,8 @@ /* printconf.c */ +void print_config(FILE *); + extern char*news_directory; extern char*news_lib_directory; extern char*master_directory; @@ -14,7 +16,6 @@ extern char*help_directory; extern char*bin_directory; extern char*db_directory; extern char*db_data_directory; -extern char*tmp_directory; extern char*log_file; extern char domain[]; -- 2.30.2 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- debconf information excluded -- Bjarni I. Gislason
Bug#984426: grub suddenly does not boot and ends up with "grub_register_command_lockdown not found"
Package: grub-pc Version: 2.02+dfsg1-20+deb10u4 Followup-For: Bug #984426 Hello, I experienced the same problem on a couple of my machines too. Yes, technically a misconfiguration at my end, but the number of me-too's suggests that there are many others not realising that debconf needs to know about *every* bootable disk to avoid this sort of issue. I know it's not your fault and is a bit annoying, but I suggest that grub check for and complain if it notices disks that have grub installed on it, yet are not listed in debconf's install_devices (eg. because at some point in the (possibly distant) past, the admin ran grub-install manually, and/or used a rescue disk to (re)install grub). In the absence of such an actual check, perhaps just put a reminder in NEWS.Debian to the effect that running grub-install behind debconf's back may have unforseen consequences, and that a bootloader installed in this way will not get updated automatically. -MD
Bug#985238: [Debian-iot-maintainers] Bug#985238: workaround , first patch
Hello, Thanks for the patch! I'm about to upload a new package to fix the postgresql install, including pgcrypto. Although upgrading the package from Debian Buster will not upgrade the database content. I added a debian/NEWS file to make this more clear on package upgrade. /Nicolas OpenPGP_0xFE82139440BD22B9.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#985326: RM: ppdm -- ROM; re-introduced with the same of an old package
Package: ftp.debian.org Severity: normal Hello, this is a follow up to #985245. src:python-ppmd has just been uploaded to NEW this can be removed at anytime thanks, Sandro
Bug#985245: src:ppmd: reintroduced with lower version number, different project?
Hello, On Sun 14 Mar 2021 at 09:39PM -04, Sandro Tosi wrote: >> Per Policy 3.2.2 this is actually RC, and there is no length of time >> after which it's Policy-compliant to reuse package name--version pairs: >> "the version numbers which a binary package must not reuse includes the >> version numbers of any versions of the binary package ever accepted into >> the archive". >> >> Please take a look at that section of Policy. Unfortunately, I think >> you're going to have to introduce an epoch. > > meh, at this point i'd rather do a one-time only operation: remove > src:ppdm and reintroduce it as src:python-ppdm. > > is there anything that i need to other than file a RM bug for src:ppdm > and then upload a new src:python-ppdm for making this transition > complete? I haven't worked through all the details, but I don't believe there is anything else. -- Sean Whitton signature.asc Description: PGP signature
Bug#985245: src:ppmd: reintroduced with lower version number, different project?
Hello, On Mon 15 Mar 2021 at 08:47PM -04, Sandro Tosi wrote: > alright, i've uploaded src:python-ppmd right now, which is just a > rename of the src:ppmd package. > > Sean, do you need me to file a RM for src:ppmd or will dak > automagically take care of it? I don't believe it will happen automatically. -- Sean Whitton signature.asc Description: PGP signature
Bug#985330: hdbm.h: add types as parameters to declarations
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From 05154477edfe69e83283d0310a811f67b5647797 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Tue, 16 Mar 2021 04:23:07 +
>Subject: [PATCH] hdbm.h: add types as parameters to declarations
hdbm.h:
Add a declaration to empty parentheses.
Add parameters as type declarations to "hdbmwalk()"
Signed-off-by: Bjarni Ingi Gislason
---
hdbm.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/hdbm.h b/hdbm.h
index 59cec4e..a60faba 100644
--- a/hdbm.h
+++ b/hdbm.h
@@ -61,10 +61,11 @@ HDBMDATUM {
#define HASHTABLE struct hashtable
#endif
-HASHTABLE *hdbmcreate(register unsigned, unsigned (*) ());
+HASHTABLE *hdbmcreate(register unsigned, unsigned (*) (void));
voidhdbmdestroy(register HASHTABLE *);
int hdbmstore(register HASHTABLE *, HDBMDATUM, HDBMDATUM);
-HDBMDATUM hdbmentry(register HASHTABLE *, HDBMDATUM, HDBMDATUM(*) ());
+HDBMDATUM hdbmentry(register HASHTABLE *, HDBMDATUM, HDBMDATUM(*)
(HDBMDATUM));
int hdbmdelete(register HASHTABLE *, HDBMDATUM);
HDBMDATUM hdbmfetch(register HASHTABLE *, HDBMDATUM);
-voidhdbmwalk(HASHTABLE *, register int (*) (), register char *);
+voidhdbmwalk(HASHTABLE *, register int (*) (HDBMDATUM,
+ HDBMDATUM, char *), register char *);
--
2.30.2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#985321: reroute.c: add a prototype for the function "reroute()"
Source: nn Version: 6.7.3-14 Severity: normal Tags: patch Dear Maintainer, >From 4a7261512c3e7ada58fb60b01c97d7e4590cbef0 Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Tue, 16 Mar 2021 01:16:27 + >Subject: [PATCH] reroute.c: add a prototype for the function "reroute()" Signed-off-by: Bjarni Ingi Gislason --- reroute.c | 1 + 1 file changed, 1 insertion(+) diff --git a/reroute.c b/reroute.c index 21b4216..1055045 100644 --- a/reroute.c +++ b/reroute.c @@ -10,6 +10,7 @@ #include "config.h" #include "global.h" +int reroute(char *, char *); int reroute(char *route, char *address) -- 2.30.2 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- debconf information excluded -- Bjarni I. Gislason
Bug#985323: pack_subject.c: add a prototype for the functinon "pack_subject()"
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From 394aec0a0f74b7ea2c200ccf73c23613b8dc7869 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Tue, 16 Mar 2021 01:40:47 +
>Subject: [PATCH] pack_subject.c: add a prototype for the function
> "pack_subject()"
Signed-off-by: Bjarni Ingi Gislason
---
pack_subject.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pack_subject.c b/pack_subject.c
index 41eaae7..1ecedcd 100644
--- a/pack_subject.c
+++ b/pack_subject.c
@@ -12,6 +12,8 @@
#include "config.h"
#include "global.h"
+int pack_subject(register char *, register char *, int *, int);
+
int
pack_subject(register char *dest, register char *src, int *re_counter_ptr, int
max_length)
{
--
2.30.2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#985245: src:ppmd: reintroduced with lower version number, different project?
> > alright, i've uploaded src:python-ppmd right now, which is just a > > rename of the src:ppmd package. > > > > Sean, do you need me to file a RM for src:ppmd or will dak > > automagically take care of it? > > I don't believe it will happen automatically. ok, i've filed #985326 for src:ppmd removal - let me know if there's any other step i need to do regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#985331: hash.c: add type declarations as parameters to functions; add a "return 1" to "hdbmtohash()"
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From 7385231dd6fad1c396e7bb351bcddf56e8dbd836 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Tue, 16 Mar 2021 05:00:23 +
>Subject: [PATCH] hash.c: add type declarations as parameters to functions; add
> a "return 1" to "hdbmtohash()"
hash.c:
Add a type declaration to empty parentheses.
Add a "return 1" to function "hdbmtohash()"; unknown purpose!
Add type declarations as parameters to the function "hashwalk()".
Signed-off-by: Bjarni Ingi Gislason
---
hash.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/hash.c b/hash.c
index 07d0081..6a214ce 100644
--- a/hash.c
+++ b/hash.c
@@ -71,7 +71,7 @@ hashdef(register HASHDATUM key)
#endif
HASHTABLE *
-hashcreate(unsigned size, unsigned (*hashfunc) ())
+hashcreate(unsigned size, unsigned (*hashfunc) (void))
/* size a crude guide to size */
{
return hdbmcreate(size, hashfunc);
@@ -146,7 +146,7 @@ hashdelete(HASHTABLE * tbl, register HASHDATUM key)
struct translate {
char *realhook;
-int (*func) ();
+int (*func) (char *, char *, char *);
};
static int
@@ -155,6 +155,7 @@ hdbmtohash(HDBMDATUM key, HDBMDATUM data, char *hook)
register struct translate *thp = (struct translate *) hook;
(*thp->func) (key.dat_ptr, data.dat_ptr, thp->realhook);
+return 1; /* added, unknown purpose */
}
/*
@@ -162,8 +163,14 @@ hdbmtohash(HDBMDATUM key, HDBMDATUM data, char *hook)
* HDBMDATUM arguments to HASHDATUM arguments. this also demonstrates
* how to use the hook argument.
*/
+
void
-hashwalk(HASHTABLE * tbl, int (*nodefunc) (), char *hook)
+/* next line changed
+ hashwalk(HASHTABLE * tbl, int (*nodefunc) (), char *hook)
+*/
+hashwalk(HASHTABLE * tbl, int (*nodefunc) (char *, char *,
+char *), char *hook)
+
/* hook (void *) really */
{
struct translate transhook;
--
2.30.2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#985252: vorta: clicking on the notification bar icon doesnt open the application
Control: tag -1 moreinfo Hi Sandro! Thanks again for these bug reports :-) Sandro Tosi writes: > Package: vorta > Version: 0.7.5-1 > Severity: normal > > Hello, > i think it's pretty natural to expect that, clicking on the vorta icon on the > notification bar, vorta will open. > > but that's not the case: i need to right click, and then select "Vorta for > Borg > Backup" menu entry for that to happen. > > Please change this behavior. > I was unable to reproduce this on either my sid system or my buster system (with local bpo of 0.7.5); both systems use KDE, and left clicking on the tray icon opens the application window in both cases. Would you please share what desktop environment, and possibly system tray application you're using? I vaguely remember this might be the case under GNOME Shell (I forget which system tray extension). Would you please also check if system-tray-using applications like transmission-qt are affected, and ideally also another PyQt system-tray-using application? I think you'll agree that we ought to verify that this isn't a more widespread Qt, PyQt, GNOME Shell, or system-tray-extension issue :-) Thanks! Nicholas signature.asc Description: PGP signature
Bug#985270: Resignation + Call for votes for new Chair
On Mon, Mar 15, 2021 at 10:30:59AM +0100, Margarita Manterola wrote: > Package: tech-ctte > > [Resending as a bug rather than a mailing-list email. Sorry!] Resending to the bug instead of the mailing list... oops > Dear TC members, > > As is traditional when committee members change, I am calling for the election > of a new Chair of Debian Technical Committee by announcing my resignation as > chair effective one week from now. In accordance with Section 6.1.7 of the > Debian Constitution, the vote runs until all members have voted, or until my > resignation takes effect. > > The ballot is the following: > > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Margarita Manterola > B : David Bremner > C : Niko Tyni > D : Gunnar Wolf > E : Simon McVittie > F : Sean Whitton > G : Elana Hashman > H : Christoph Berg > > ===END=== I vote: B > F > C = D = E > A = G > H - e signature.asc Description: PGP signature
Bug#985328: awksplit.c: include the header file "awksplit.h"
Source: nn Version: 6.7.3-14 Severity: normal Tags: patch Dear Maintainer, >From 7e5b91de210cef84d001c54c88c67c85bf27199b Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Tue, 16 Mar 2021 03:56:33 + >Subject: [PATCH] awksplit.c: include the header file "awksplit.h" Signed-off-by: Bjarni Ingi Gislason --- awksplit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/awksplit.c b/awksplit.c index 031e53b..e354168 100644 --- a/awksplit.c +++ b/awksplit.c @@ -52,6 +52,7 @@ a fair bit of unused code. */ #include +#include "awksplit.h" #include "config.h" #include "split.h" -- 2.30.2 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- debconf information excluded -- Bjarni I. Gislason
Bug#985288: [Pkg-javascript-devel] Bug#985288: chai: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Le 15/03/2021 à 13:30, Andreas Beckmann a écrit : > Package: chai > Version: 4.2.0+ds+~4.2.14-3 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > an upgrade test with piuparts revealed that your package installs files > over existing symlinks and possibly overwrites files owned by other > packages. This usually means an old version of the package shipped a > symlink but that was later replaced by a real (and non-empty) > directory. This kind of overwriting another package's files cannot be > detected by dpkg. > > This was observed on the following upgrade paths: > > buster -> bullseye > > For /usr/share/doc/PACKAGE this may not be problematic as long as both > packages are installed, ship byte-for-byte identical files and are > upgraded in lockstep. But once one of the involved packages gets > removed, the other one will lose its documentation files, too, > including the copyright file, which is a violation of Policy 12.5: > https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information > > For other overwritten locations anything interesting may happen. > > Note that dpkg intentionally does not replace directories with symlinks > and vice versa, you need the maintainer scripts to do this. > See in particular the end of point 4 in > https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade > > It is recommended to use the dpkg-maintscript-helper commands > 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) > to perform the conversion, ideally using d/$PACKAGE.maintscript. > See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. > > > From the attached log (scroll to the bottom...): > > 0m40.7s ERROR: FAIL: silently overwrites files via directory symlinks: > /usr/share/doc/chai/History.md.gz (chai) != > /usr/share/doc/libjs-chai/History.md.gz (libjs-chai) > /usr/share/doc/chai -> libjs-chai > /usr/share/doc/chai/changelog.Debian.gz (chai) != > /usr/share/doc/libjs-chai/changelog.Debian.gz (libjs-chai) > /usr/share/doc/chai -> libjs-chai > /usr/share/doc/chai/changelog.gz (chai) != > /usr/share/doc/libjs-chai/changelog.gz (libjs-chai) > /usr/share/doc/chai -> libjs-chai > /usr/share/doc/chai/copyright (chai) != /usr/share/doc/libjs-chai/copyright > (libjs-chai) > /usr/share/doc/chai -> libjs-chai Hi, there is already a maintscript for this: $ cat debian/chai.maintscript dir_to_symlink /usr/share/doc/chai libjs-chai 4.2.0+ds-2~ What is wrong here ?
Bug#985151: dh_bash-completion: treats nitrokey-app file list as script
Hi Gabriel,
On Mon, 2021-03-15 at 09:52 -0300, Gabriel F. T. Gomes wrote:
> On Sat, 13 Mar 2021, Kevin Locke wrote:
>> I've attached a patch to fix the issue by requiring complete to follow a
>> line break or semicolon. It obviously does not address the root of the
>> problem of reliably differentiating a list of paths from a Bash script.
>> (Which is not really possible, since a list of paths is a valid bash
>> script.) But it may be a sufficient quick fix until/unless #785271 is
>> addressed.
>
> I'm not sure we will ever be able to correctly detect everything...
> Anyhow, your patch looks not only sufficient, but correct on its own.
> I'll check if it works correctly with the scripts currently installed
> under my /usr/share/bash-completion.
>
> Also, the detection algorithm has been kindly written by sergiodj (CC),
> so I'll give him some time to weigh in, then I'll apply your fix.
Thanks for reviewing the patch! While looking at it again this morning,
I noticed a potential issue: The patched version wouldn't match the last
line of
_have mycommand && _mycommand() {
...
} && complete ...
Which appears to be a common idiom for only defining the function and
completion if the command is in $PATH. I've attached an updated version
which matches & and | in addition to ; as command separators. We may
also want to consider modifying the compgen expression in the same way.
Thanks again,
Kevin
>From 1b21115318d9620ac7770f1051a536c8a8f3139f Mon Sep 17 00:00:00 2001
Message-Id: <1b21115318d9620ac7770f1051a536c8a8f3139f.1615813233.git.ke...@kevinlocke.name>
From: Kevin Locke
Date: Sat, 13 Mar 2021 10:18:37 -0700
Subject: [PATCH v2] dh_bash-completion: Tighten is_filelist matching
The regular expressions in is_filelist which matches "well-known idioms
on bash scripts" currently matches the path to the bash-completion
script in the nitrokey-app package:
'data/bash-autocomplete/nitrokey-app' =~ /\s*complete.*-[A-Za-z].*/
Avoid this by ensuring the is only matched when following a line break
or character which can be used to chain shell commands.
Signed-off-by: Kevin Locke
---
debian/extra/debhelper/dh_bash-completion | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Changes in v2:
* Match & and | in addition to ; as command separators.
This is important for `... && complete`, which is a common idiom.
diff --git a/debian/extra/debhelper/dh_bash-completion b/debian/extra/debhelper/dh_bash-completion
index d1d9bf2e..7999151c 100755
--- a/debian/extra/debhelper/dh_bash-completion
+++ b/debian/extra/debhelper/dh_bash-completion
@@ -75,7 +75,7 @@ sub is_filelist {
#
# - If we see an "if...then" construction in the file. We
# take into account multi-line statements.
- if (/\s*complete.*-[A-Za-z].*/
+ if (/(^|[|&;])\s*complete.*-[A-Za-z].*/
|| /\$\(.*\)/
|| /\s*compgen.*-[A-Za-z].*/
|| /\s*if.*;.*then/s) {
--
2.30.2
Bug#985295: qbs-examples: unhandled symlink to directory conversion: /usr/share/qbs/examples/cocoa-application/CocoaApplication/en_US.lproj -> en.lproj
Package: qbs-examples Version: 1.18.0-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster -> bullseye For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): Preparing to unpack .../qbs-examples_1.18.0-4_all.deb ... Unpacking qbs-examples (1.18.0-4) over (1.12.2+dfsg-2) ... dpkg: error processing archive /var/cache/apt/archives/qbs-examples_1.18.0-4_all.deb (--unpack): unable to install new version of '/usr/share/qbs/examples/cocoa-application/CocoaApplication/en_US.lproj/Credits.rtf': No such file or directory Errors were encountered while processing: /var/cache/apt/archives/qbs-examples_1.18.0-4_all.deb In buster /usr/share/qbs/examples/cocoa-application/CocoaApplication/en_US.lproj was a symlink to en.lproj. cheers, Andreas qbs-examples_1.18.0-4.log.gz Description: application/gzip
Bug#985294: check_memory plugin not working when default locale is not English
Package: monitoring-plugins-contrib Version: 31.20210225 Severity: normal Tags: upstream patch Dear Maintainer, The check_memory plugin doesn't work since upgrading to bullseye because it appears the procps package has adopted some new translations for /usr/bin/free but the plugin expects English output. Setting LANG=C as part of the command avoids the parsing error. A merge request has been submitted to Salsa at this URL: https://salsa.debian.org/lavamind/pkg-nagios-plugins-contrib/-/merge_requests/1 Thank you! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/12 CPU threads) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled monitoring-plugins-contrib depends on no packages. Versions of packages monitoring-plugins-contrib recommends: ii bind9-host 1:9.16.12-1 ii binutils 2.35.2-2 ii curl 7.74.0-1.1 ii debsecan 0.4.20.1 ii file 1:5.39-3 ii freeipmi-tools 1.6.6-3 ii libc62.31-9 ii libdata-validate-domain-perl 0.10-1.1 ii libdata-validate-ip-perl 0.27-1 ii libdate-manip-perl 6.83-1 ii libdbd-mysql-perl4.050-3+b1 ii libio-socket-ssl-perl2.069-1 ii libipc-run-perl 20200505.0-1 ii liblocale-gettext-perl 1.07-4+b1 ii liblwp-useragent-determined-perl 1.07-1.1 ii libmail-imapclient-perl 3.42-1 ii libmemcached11 1.0.18-4.2 ii libmonitoring-plugin-perl0.40-1 ii libnet-cups-perl 0.64-1+b3 ii libnet-dns-perl 1.29-1 ii libnet-dns-sec-perl 1.18-1+b1 ii libnet-smtp-ssl-perl 1.04-1 ii libnet-smtp-tls-perl 0.12-3 ii libnet-smtpauth-perl 0.08-4.1 ii libnet-snmp-perl 6.0.1-6 ii libnet-ssleay-perl 1.88-3+b1 ii libreadonly-perl 2.050-3 ii libredis-perl2:1.9980-2 ii libtimedate-perl 2.3300-2 ii libwebinject-perl1.94-1 ii libxml-simple-perl 2.25-1 ii monitoring-plugins-basic [nagios-plugins-basic] 2.3-1 ii openssl 1.1.1j-1 ii perl 5.32.1-3 ii perl-base [libsocket-perl] 5.32.1-3 ii python3 3.9.1-1 ii python3-pymongo 3.11.0-1+b1 ii ruby 1:2.7+2 ii snmp 5.9+dfsg-3+b1 ii whois5.5.8 Versions of packages monitoring-plugins-contrib suggests: pn backuppc pn cciss-vol-status pn expect pn libsys-virt-perl pn moreutils pn mpt-status pn nagios-plugin-check-multi pn percona-toolkit pn perl-doc pn python3-boto pn smstools -- no debconf information OpenPGP_signature Description: OpenPGP digital signature
Bug#984997: [debian-mysql] Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment
Hello, I would agree that passing secrets on the command line is insecure and in this case unnecessary, there is an easy fix for that and it will be implemented. Speaking of environment, AFAIK on modern systems it can be read only by sufficiently privileged user, so I don't see how it is less secure than a file (which will have to have the same permissions as /proc//environ). Could you elaborate how is it less secure than using --defaults-extra-file? AFAIK xtrabackup/mariabackup script does not support passing passwords via file descriptor, so that option does not seem to be practical. Kind regards, Alex On 2021-03-14 13:20, Marc Lehmann wrote: On Thu, Mar 11, 2021 at 09:49:03PM +0200, Otto Kekäläinen wrote: Thanks for looking into this and reporting it. Could you be a bit more specific what the context is, who can view the command? This is a rather old and wlel-known type of security issue. Typically any local user can view the password. This data is also often exposed in monitoring output, http status pages, smtp and so on. The comandline and environment are simply the wrong places to expose secret data - passwords should never be shown on screen in cleartext. (That includes the environment, btw. storing secrets in environment variables is similarly insecure). How do you suggest the password would be passed? The typical method that is employed in practise is passing it via a file descriptor. A bit less secure is using a (non-world-readable) file, e.g. using --defaults-extra-file.
Bug#984488: I've met the same bug
Hello, After upgrading grub from 2.02+dfsg1-20+deb10u3 to 2.02+dfsg1-20+deb10u4 I've met the same bug on all boxes with MD raid1 partition starting from sector 63. /boot/grub/i386-pc/core.img is 31120 bytes and should fit, but i get: Installing for i386-pc platform. grub-install: warning: your core.img is unusually large. It won't fit in the embedding area. grub-install: error: embedding is not possible, but this is required for RAID and LVM install. Rolling back to 2.02+dfsg1-20+deb10u3 solves the problem and everything works with the same core.img (MD5 is the same).
Bug#985039: media-types: please bring back application/x-shockwave-flash
Hi Pierre, thank you for the detailed explanations. So the problem is the Flash plugin, which is not supported upstream nor distributed by Debian anymore. While it was not my intention to make its use more difficult, I wonder if the change is not a bad thing. After all, users who really want to use it can simply add back the x-shockwave-flash media type in `/etc/mime.types` and solve the problem locally. In any case, I think that it would be too late to revert the change in the package before the release. I may consider to request a Stable update if other users support your point of view, but at the moment I think that I will simply leave the situation as it is. Please do not hesitate to ping me a couple of weeks after the release if you would like. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Bug#985296: e2fsprogs: Latest buster-backports build 1.46.1-1_bpo10+1 fails to install
Package: e2fsprogs Version: 1.46.1-1~bpo10+1 Severity: important Tags: a11y Dear Maintainer, Tried to do automatic update of installed packages and e2fsprogs, e2fsprogs-l10n, fusee2fs and libext2fs2 packages held back as they have dependency on libblkid1, requiring >= 2.36 and Buster only has 2.33.1-0.1 available The following packages have unmet dependencies: e2fsprogs : PreDepends: libblkid1 (>= 2.36) but 2.33.1-0.1 is to be installed -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE, TAINT_AUX Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages e2fsprogs depends on: ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libcom-err2 1.46.2-1~bpo10+1 ii libext2fs2 1.46.1-1~bpo10+1 ii libss2 1.46.2-1~bpo10+1 ii libuuid1 2.33.1-0.1 ii logsave 1.46.2-1~bpo10+1 Versions of packages e2fsprogs recommends: ii e2fsprogs-l10n 1.46.1-1~bpo10+1 Versions of packages e2fsprogs suggests: pn e2fsck-static ii fuse2fs 1.46.1-1~bpo10+1 pn gpart ii parted 3.2-25 -- no debconf information
Bug#985278: Package at salsa
Package is available at https://salsa.debian.org/python-team/packages/python-evilunit
Bug#985275: Package at salsa
Package is available at https://salsa.debian.org/python-team/packages/swagger-marshmallow-codegen
Bug#985279: Package at salsa
Package available at https://salsa.debian.org/python-team/packages/python-magicalimport
Bug#985280: Package at salsa
Package available at https://salsa.debian.org/python-team/packages/python-prestring
Bug#985291: Package at salsa
Package available at https://salsa.debian.org/python-team/packages/python-dictknife
Bug#985151: dh_bash-completion: treats nitrokey-app file list as script
Hi, Kevin, On Sat, 13 Mar 2021, Kevin Locke wrote: > > I've attached a patch to fix the issue by requiring complete to follow a > line break or semicolon. It obviously does not address the root of the > problem of reliably differentiating a list of paths from a Bash script. > (Which is not really possible, since a list of paths is a valid bash > script.) But it may be a sufficient quick fix until/unless #785271 is > addressed. I'm not sure we will ever be able to correctly detect everything... Anyhow, your patch looks not only sufficient, but correct on its own. I'll check if it works correctly with the scripts currently installed under my /usr/share/bash-completion. Also, the detection algorithm has been kindly written by sergiodj (CC), so I'll give him some time to weigh in, then I'll apply your fix. > Thanks for considering, Thank you! Cheers, Gabriel
Bug#981372: 2.6.3 and 2.6.4 are bugfix releases too
On Mon, Mar 15, 2021 at 11:19:10AM +0100, Tobias wrote: > > Keeping this package up to date in sid would gives us the option to > install it. The keepassxc browser integration depends on up to date > keepassxc application. Bug fix releases are not allowed, only small, targeted fixes. Since a month now. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#985288: [Pkg-javascript-devel] Bug#985288: chai: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Le 15/03/2021 à 13:49, Yadd a écrit : > Le 15/03/2021 à 13:30, Andreas Beckmann a écrit : >> Package: chai >> Version: 4.2.0+ds+~4.2.14-3 >> Severity: serious >> User: debian...@lists.debian.org >> Usertags: piuparts >> >> Hi, >> >> an upgrade test with piuparts revealed that your package installs files >> over existing symlinks and possibly overwrites files owned by other >> packages. This usually means an old version of the package shipped a >> symlink but that was later replaced by a real (and non-empty) >> directory. This kind of overwriting another package's files cannot be >> detected by dpkg. >> >> This was observed on the following upgrade paths: >> >> buster -> bullseye >> >> For /usr/share/doc/PACKAGE this may not be problematic as long as both >> packages are installed, ship byte-for-byte identical files and are >> upgraded in lockstep. But once one of the involved packages gets >> removed, the other one will lose its documentation files, too, >> including the copyright file, which is a violation of Policy 12.5: >> https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information >> >> For other overwritten locations anything interesting may happen. >> >> Note that dpkg intentionally does not replace directories with symlinks >> and vice versa, you need the maintainer scripts to do this. >> See in particular the end of point 4 in >> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade >> >> It is recommended to use the dpkg-maintscript-helper commands >> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) >> to perform the conversion, ideally using d/$PACKAGE.maintscript. >> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >> >> >> From the attached log (scroll to the bottom...): >> >> 0m40.7s ERROR: FAIL: silently overwrites files via directory symlinks: >> /usr/share/doc/chai/History.md.gz (chai) != >> /usr/share/doc/libjs-chai/History.md.gz (libjs-chai) >> /usr/share/doc/chai -> libjs-chai >> /usr/share/doc/chai/changelog.Debian.gz (chai) != >> /usr/share/doc/libjs-chai/changelog.Debian.gz (libjs-chai) >> /usr/share/doc/chai -> libjs-chai >> /usr/share/doc/chai/changelog.gz (chai) != >> /usr/share/doc/libjs-chai/changelog.gz (libjs-chai) >> /usr/share/doc/chai -> libjs-chai >> /usr/share/doc/chai/copyright (chai) != >> /usr/share/doc/libjs-chai/copyright (libjs-chai) >> /usr/share/doc/chai -> libjs-chai > > Hi, > > there is already a maintscript for this: > > $ cat debian/chai.maintscript > dir_to_symlink /usr/share/doc/chai libjs-chai 4.2.0+ds-2~ > > What is wrong here ? Found: s/dir_to_symlink/symlink_to_dir/ :-(
Bug#985151: dh_bash-completion: treats nitrokey-app file list as script
On Mon, 15 Mar 2021, Gabriel F. T. Gomes wrote: > > I'll check if it works correctly with the scripts currently installed > under my /usr/share/bash-completion. Perhaps we could also add && and || as command termination characters, so that idioms like the following also get detected: complete -o bashdefault -o default -o nospace -F $wrapper $1 2>/dev/null \ || complete -o default -o nospace -F $wrapper $1 (from /usr/share/bash-completion/completions/gitk) test -s /usr/share/osc/complete && complete -o default -C /usr/share/osc/complete osc (from /usr/share/bash-completion/completions/osc)
Bug#985151: dh_bash-completion: treats nitrokey-app file list as script
On Mon, 15 Mar 2021, Kevin Locke wrote: > > Which appears to be a common idiom for only defining the function and > completion if the command is in $PATH. I've attached an updated version > which matches & and | in addition to ; as command separators. We may > also want to consider modifying the compgen expression in the same way. Oh, thank you!! We both noticed it! :) Cheers, Gabriel
Bug#962596: Divergence in Symantec CA blacklist reverting between sid and *stable?
On Sat, Mar 13, 2021 at 08:32:32PM +, Thorsten Glaser wrote: > Hi, > > the changelogs seem to differ in re-added certificates: > Yes, they're different. I'm not sure what you're asking. Cheers, Julien
Bug#985297: libreoffice-common: needs Conflicts against all packages shipping files in /usr/lib/libreoffice/share/registry
Package: libreoffice-common Version: 1:7.0.4-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + libreoffice-writer libreoffice-draw libreoffice-calc libreoffice-base libreoffice-math Hi, during a test with piuparts I noticed your package fails to upgrade from 'buster'. It installed fine in 'buster', then the upgrade to 'bullseye' fails. >From the attached log (scroll to the bottom...): Preparing to unpack .../0-ure_1%3a7.0.4-3_amd64.deb ... Unpacking ure (1:7.0.4-3) over (6.1.5-3+deb10u7) ... Preparing to unpack .../1-libreoffice-style-colibre_1%3a7.0.4-3_all.deb ... Unpacking libreoffice-style-colibre (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ... dpkg: considering deconfiguration of libreoffice-writer, which would be broken by installation of libreoffice-core ... dpkg: yes, will deconfigure libreoffice-writer (broken by libreoffice-core) Preparing to unpack .../2-libreoffice-core_1%3a7.0.4-3_amd64.deb ... De-configuring libreoffice-writer (1:6.1.5-3+deb10u7) ... Unpacking libreoffice-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ... dpkg: considering removing libreoffice-writer in favour of libreoffice-common ... dpkg: libreoffice-writer is not properly installed; ignoring any dependencies on it dpkg: yes, will remove libreoffice-writer in favour of libreoffice-common Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ... dpkg-maintscript-helper: error: file '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 'libreoffice-common:all' dpkg-maintscript-helper: error: directory '/usr/lib/libreoffice/share/registry' contains files not owned by package libreoffice-common:all, cannot switch to symlink dpkg: error processing archive /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb (--unpack): new libreoffice-common package pre-installation script subprocess returned error exit status 1 rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory Selecting previously unselected package libreoffice-writer. dpkg: considering deconfiguration of libreoffice-common, which would be broken by installation of libreoffice-writer ... dpkg: yes, will deconfigure libreoffice-common (broken by libreoffice-writer) Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ... De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ... Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ... Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ... Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ... Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ... Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ... Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ... Errors were encountered while processing: /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb You already have all the needed Conflicts ... In this complicated upgrade case I don't see a solution to get dpkg-maintscript-helper dir_to_symlink to work properly ... Therefore I'd suggest to not use dir_to_symlink here ... but to fixup the link in postinst configure: if [ ! -L /usr/lib/libreoffice/share/registry ]; then if [ -d /usr/lib/libreoffice/share/registry ]; then # this will fail if the directory is not yet empty rmdir /usr/lib/libreoffice/share/registry fi ln -s /etc/libreoffice/registry /usr/lib/libreoffice/share/registry fi I would actually go for the fail-if-not-empty case and fix up all the upgrade paths triggering this. cheers, Andreas PS: for a log time I thought this was just another bug caused by dpkg bug #983855 but I'm now using a patched dpkg in my piuparts instance ... libreoffice-writer_1:7.0.4-3.log.gz Description: application/gzip
Bug#983204: [git-buildpackage/master] tests/11_test_dch_main.py: Fix OS release check for Ubuntu.
tag 983204 pending thanks Date: Mon Mar 15 14:42:02 2021 +0100 Author: Logan Rosen Commit ID: a54baad8f05adb7a0eb772613f69716631460d2d Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=a54baad8f05adb7a0eb772613f69716631460d2d Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=a54baad8f05adb7a0eb772613f69716631460d2d tests/11_test_dch_main.py: Fix OS release check for Ubuntu. Closes: #983204
Bug#985263: librust-num-bigint+quickcheck-macros-dev: depends on unavailable librust-quickcheck-macros-0.8-dev
Package: librust-num-bigint+quickcheck-macros-dev Version: 0.2.6-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package is not installable in sid: The following packages have unmet dependencies: librust-num-bigint+quickcheck-macros-dev : Depends: librust-quickcheck-macros-0.8-dev but it is not installable Cheers, Andreas
Bug#985033: debian/copyright is not up-to-date: coderay seems to have been relicensed under MIT license
On Fri, 12 Mar 2021 01:30:19 +0100 Daniel Leidert wrote: > Source: coderay > Version: 1.1.3-3 > Severity: serious > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > It seem the coderay sources are now licensed under the MIT license and not > under the LGPL license. debian/copyright seems to be outdated and wrong here. > > Regards, Daniel > > > - -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > - -- no debconf information > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmBKthsACgkQS80FZ8KW > 0F387w//ezc1er6Hv8c7swmmwgK8XfokzAcxFbktXyIsUOwN+s2fKlFwjinFkArU > PP8lOe7qzB2vB5eol19vofYdDzJoOqo/RCzsS+Q8Rm3gUzcyTF2pIeubzlNqZMf2 > KMYaERHnfrGlLklcOzt+x8JfRvmxS2MAFHNLBuws0k9yISdWfW36DeCFiz0Miqik > VrPAaWMRFUzaqnH3lXEoi342OomkDq2wmx7YnqRd4ESHTWdpAY5b9dC8r6tCnynj > zcspt/0uPnXBKKPuBKXsucBoLr80te+x/7DZ/iLILAbIdEZ+o1jzCu3pCRXQUFdK > vNOnwaBVhDl9aciXTrj1ocbNS1shximlu6vJMaMTB5MXVNt5ph691jazr6bYXjn2 > MZU8EK5fkPnYIkX3DOGGZMjuQ5wMN55Z3Udgf+pUE9oXDprc+0vxuLmq6UtLrHKy > uQm/WOd3Fj+r71s5zaRqlf7gShQU2oV23/4PLWC84nswoGkZTnk9yj5X4tw+HdfS > 82+iOGayRny2a+EkglGT4IvOvXSdPnXnucjronzpf6s5kw/JP9BRyyF85AWM87q2 > 6zjycLQo+j3xh3CV4jgNC9pRC6yUTj5YsxnYPIM7v0YWgQBwEzAz6JLBMU/2zEvO > JRHm+XskHA+U6PsV4ccyA4m7zEKPsV10xRrqrZhQekf96BvaQ8Y= > =GfoC > -END PGP SIGNATURE- > > Submitted a merge request[1] which closes this bug. [1] - https://salsa.debian.org/ruby-team/coderay/-/merge_requests/1 -- Greetings, Vivek K J vive...@tchncs.de www.vivekkj.me
Bug#985256: backintime-qt: unmount at wrong time leads to core dump
Package: backintime-qt Version: 1.2.1-2 Severity: normal X-Debbugs-Cc: none, Francesco Potortì When closing the settings dialog, the unmount function is called in the user_callback, while it should not. Depending on other actions, this sometimes leads to a core dump when closing the application. This sequece of actions dumps core: - open the gui (this results in mounting a volume via callback) - open the settings dialog - close it (this results in unmountng the volume via callback) - look at the logs using the menu - exit (this dumps core) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (101, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages backintime-qt depends on: ii backintime-common1.2.1-2 ii libnotify-bin0.7.9-3 ii policykit-1 0.105-30 ii python3 3.9.2-2 ii python3-dbus.mainloop.pyqt5 5.15.2+dfsg-3 ii python3-pyqt55.15.2+dfsg-3 ii x11-utils7.7+5 Versions of packages backintime-qt recommends: ii python3-secretstorage 3.3.1-1 Versions of packages backintime-qt suggests: ii meld 3.20.2-2 -- no debconf information
Bug#985039: media-types: please bring back application/x-shockwave-flash
> I replaced it with application/vnd.adobe.flash.movie, which was > registered in 2013. > > https://www.iana.org/assignments/media-types/application/vnd.adobe.flash.movie > > Sorry that it was not prominently explained in the changelog. No, it's my bad, the changelog actually stated exactly what was done. I didn't investigate this issue in one time and I must have dismissed and overlooked this new type as not a replacement, on the basis that it was broken for me. I'm getting a crash course here on the different media type components on my system, thanks for clarifying what was intended. > Can you give me details on what is broken by this change ? When opening about:plugins in Firefox, the Flash plugin lists: MIME Type | Description | Suffixes application/x-shockwave-flash | Shockwave Flash | swf application/futuresplash | FutureSplash Player | spl I'm going to surmise that it's the plugin itself that registers which media types it handles; and application/vnd.adobe.flash.movie is not one of them. Consequently, when I open in a new Firefox tab an HTTP URL to an SWF file, if it's served with an application/vnd.adobe.flash.movie HTTP Content-Type header, the Flash plugin doesn't load and I'm prompted to download the file. If it's served with an application/x-shockwave-flash Content-Type, the Flash plugin loads to run the content. As I mentioned, it might also be SWF animations saved on a local drive. So when I open a file:// URL to an SWF file, or use the File > Open dialog, which apparently leads to opening a file:// URL all the same, there is no Content-Type header: and thus I surmise it relies solely on the /etc/mime.types mappings. And opening a file with an .swf extension, prompts me for download with the new application/vnd.adobe.flash.movie mapping, whereas it loads the Flash plugin fine with the old application/x-shockwave-flash mapping. I get the same results over HTTP with no Content-Type. So that's what broken for me. I've tried this an a couple old Firefox versions, because up-to-date versions of major browsers since January now refuse to load and register the Flash plugin altogether, which I've also reported as an offensive issue in itself. I haven't tried any of the alternate products I've mentioned to keep playing Flash content, so I don't know how they handle this; that might be worth checking. It's also unclear to me whether application/vnd.adobe.flash.movie was really registered by an Adobe employee from the Flash maintenance team. Maybe I'm wrong in my analysis of which component would be responsible for handling the media type, but if I'm right, it sure is a shame that the Adobe Flash plugin was never updated to support the registered vendor type; and now it's reached its final version so it's probably unfortunately too late. So considering that the policy is to avoid duplicate mappings, I would suggest reverting .swf to application/x-shockwave-flash, due to lacking support for application/vnd.adobe.flash.movie :/ -- Pierre Ynard
Bug#985259: urlview: Add support for Gemini URLs
Package: urlview
Version: 0.9-21
Severity: wishlist
Tags: patch upstream
Dear Maintainer,
Gemini is a system to access information on the Internet. A competitor of the
Web for some use cases. It is described at https://gemini.circumlunar.space/
Gemini uses URLs.
The patch in the configuration files allow urlview to access Gemini URLs. At
the present time, there is in sid only one Gemini client, the Emacs mode
Elpher. In the mean time, I added two common clients in the configuration file.
I assume that the integration of my patch will have to wait for these clients
to be packaged?
-- System Information:
Debian Release: 10.7
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 4.19.0-14-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages urlview depends on:
ii libc6 2.28-10
ii libncurses6 6.1+20181013-2+deb10u2
ii libtinfo6 6.1+20181013-2+deb10u2
ii sensible-utils 0.0.12
Versions of packages urlview recommends:
ii firefox-esr [www-browser] 78.7.0esr-1~deb10u1
ii lynx [www-browser] 2.8.9rel.1-3
ii w3m [www-browser] 0.5.3-37
Versions of packages urlview suggests:
ii mutt 1.10.1-2.1+deb10u5
ii ncftp 2:3.2.5-2.1
ii wget 1.20.1-1.1
-- Configuration Files:
/etc/urlview/system.urlview changed:
REGEXP (((http|https|ftp|gopher|gemini)|mailto):(//)?[^
<>"\t]*|(www|ftp)[0-9]?\.[-a-z0-9.]+)[^ .,;\t\n\r<">\):]?[^, <>"\t]*[^
.,;\t\n\r<">\):]
COMMAND /etc/urlview/url_handler.sh
/etc/urlview/url_handler.sh changed:
http_prgs="/usr/bin/sensible-browser:PW /usr/bin/sensible-browser:XT
/usr/bin/galeon:PW /usr/bin/konqueror:PW /usr/bin/mozilla:PW /usr/bin/lynx:XT
/usr/bin/w3m:XT /usr/bin/links:XT"
https_prgs=$http_prgs
mailto_prgs="/usr/bin/mutt:VT /usr/bin/elm:VT /usr/bin/alpine:VT
/usr/bin/pine:VT /usr/bin/mail:VT"
gopher_prgs="/usr/bin/gopher:XT /usr/bin/lynx:XT"
gemini_prgs="/usr/local/bin/lagrange:XW /usr/bin/amfora:XT"
ftp_prgs="/usr/bin/ncftp:XT /usr/bin/lftp:XT $http_prgs"
file_prgs="/usr/bin/wget:XT /usr/bin/snarf:XT"
XTERM=/usr/bin/x-terminal-emulator
function getprg()
{
local ele tag prog
for ele in $*
do
tag=${ele##*:}
prog=${ele%%:*}
if [ -x $prog ]; then
case $tag in
PW) [ -n "$DISPLAY" ] && echo "P:$prog" && return 0
;;
XW)
[ -n "$DISPLAY" ] && echo "X:$prog" && return 0
;;
XT)
[ -n "$DISPLAY" ] && [ -x "$XTERM" ] && \
echo "X:$XTERM -e $prog" && return 0
echo "$prog" && return 0
;;
VT)
echo "$prog" && return 0
;;
esac
fi
done
}
url=$1; shift
type=${url%%:*}
if [ "$url" = "$type" ]; then
type=${url%%.*}
case $type in
www|web|www[1-9])
type=http
;;
esac
url=$type://$url
fi
if [ "$type" = "ftp" ]; then
filename=${url##*/}
if [ $filename ]; then
echo "Is \"$filename\" a file? (y/N)";
read x
case $x in
y|Y)
type=file
;;
*)
;;
esac
fi
fi
case $type in
https)
prg=`getprg $https_prgs`
;;
http)
prg=`getprg $http_prgs`
;;
ftp)
prg=`getprg $ftp_prgs`
;;
mailto)
prg=`getprg $mailto_prgs`
;;
gopher)
prg=`getprg $gopher_prgs`
;;
gemini)
prg=`getprg $gemini_prgs`
;;
file)
prg=`getprg $file_prgs`
;;
*)
echo "Unknown URL type. Please report URL and viewer to"
echo "urlv...@packages.debian.org."
echo -n "Press enter to continue.."; read x
exit
;;
esac
if [ -n "$prg" ]; then
if [ "${prg%:*}" = "P" ]; then
nohup ${prg#*:} $url 2>/dev/null 1>/dev/null &
elif [ "${prg%:*}" = "X" ]; then
${prg#*:} $url 2>/dev/null &
else
$prg $url
fi
fi
-- no debconf information
Bug#985264: librust-html2text-dev: depends on unavailable librust-clippy-0.0.302+default-dev
Package: librust-html2text-dev Version: 0.2.1-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package is not installable in sid: The following packages have unmet dependencies: librust-html2text-dev : Depends: librust-clippy-0.0.302+default-dev but it is not installable Cheers, Andreas
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Mathias, Thank you for an interesting ITP. It would be nice to have openrct2 in Debian. I have reviewed your packaging, and saw libcurl4-openssl-dev among the build dependencies. Do you know what does openrct2 need it for? My concern here is that in-game network access/downloads may interfere with Debian policies. On 2021-03-13 20:21, Mathias Gibbens wrote: > Upstream released v0.3.3 earlier today, and I have updated my > packaging accordingly. Additionally, I updated the distribution to > experimental, as the bullseye freeze is in full swing. I believe uploads to unstable are discouraged only for packages already in testing, so targeting unstable here should be OK. Best, Andrius
Bug#985158: [pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options
Werner Koch wrote... > On Sun, 14 Mar 2021 14:32, Christoph Biedl said: > > > Point is, the legacy file ~/.gnupg/options is still being used in > > surprisingly many applications, also in documentation: > > Then please file a bug against such documentation. And maybe even > against any application which read the option filre directly, that is > without using gpgconf. If Debian were not rather late in the freeze for Bullseye, I would already have started the according procedure (Mass Bug Filing). But given the release progress, this will not succeed in time. For *after* the release, everything will be possible. My intent is to keep impact for the current release low. > > https://codesearch.debian.net/search?q=.gnupg%2Foptions=1 > > Look at the code shown tehre: Almost everywhere it is used as a fallback > from gpg.conf. Still some places do, or point to the wrong location. Also there might be other programs that rely on the legacy location. "Turning things off permanently is surprisingly difficult." > > In Debian, revert that commit, and emit a deprecation warning if the > > legacy file is parsed. > > Sysadmins will kill you if you do that. The global conf file has been a > long standing request from many parties. It comes very hadny for large > installations because it can be used to enforce options on users. That > is why I took the trouble to actually backported this from master. No doubt about the benefits of the new concept. However, sysadmins of Debian systems could not benefit from that (yet), so I feel safe. Still there are a lot of reasons why reverting is a bad idea, I will not follow that approach. > Supporting the legacy option file would be a Bad Idea. In particular > for a new major release it should be not a problem to add release notes > mention that after 18 years the deprecated legacy option file is not > anymore supported. While it was deprecated a long time ago, until very recently users had little chance to know about this, and therefore no reason to adopt. So this comes as a surprise, and as a short-time and massive change, as seen in this bug report. I really want to avoid users' workflows will break galore, possibly without even being really noticed. The best solution would have been to start emitting deprecating warnings at some point in the past. But past cannot be changed. My preferred solution was to restore the old behaviour for a limited time, i.e. parsing the legacy config file, plus emitting that warning. This will give everybody a chance to adjust their configuration. Second in preference was to only emit that warning, without processing the file. Providing a warning in the release notes and other places is very easy to do. But from experience I doubt this reaches the majority of affected users in time. Which is why I except to create havoc if this was the only reaction to this change. Christoph signature.asc Description: PGP signature
Bug#985261: toxiproxy-cli: DEPRECATED Action signature. Must be `cli.ActionFunc`.
Package: toxiproxy-cli Version: 2.0.0+dfsg1-6+b21 Severity: normal Dear Maintainer, Every time I use toxiproxy-cli, it emits an error message: michael@cnspc18:~$ toxiproxy-cli create test -l localhost:4242 -u example.com:4242 Created new proxy test DEPRECATED Action signature. Must be `cli.ActionFunc`. This is an error in the application. Please contact the distributor of this application if this is not you. See https://github.com/urfave/cli/blob/master/CHANGELOG.md#deprecated-cli-app-action-signature Thanks, -MD -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (485, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages toxiproxy-cli depends on: ii libc6 2.31-3 toxiproxy-cli recommends no packages. toxiproxy-cli suggests no packages. -- debconf-show failed
Bug#985262: librust-migrations-internals+barrel-dev: depends on unavailabe librust-barrel+default-dev
Package: librust-migrations-internals+barrel-dev Version: 1.4.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package is not installable in sid: The following packages have unmet dependencies: librust-migrations-internals+barrel-dev : Depends: librust-barrel+default-dev (< 0.2.1-~~) Depends: librust-barrel+diesel-filled-dev (< 0.2.1-~~) but it is not installable Cheers, Andreas
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi again, I fail to build the package as of e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the following error log (only the last lines): find ./debian -name libopenrct2.a -delete find ./debian -empty -type d -delete make[1]: Leaving directory '/<>' dh_install dh_install: warning: Cannot find (any matches for) "objects/*" (tried in ., debian/tmp) dh_install: warning: openrct2-data missing files: objects/* dh_install: warning: Cannot find (any matches for) "title-sequences/*" (tried in ., debian/tmp) dh_install: warning: openrct2-data missing files: title-sequences/* dh_install: error: missing files, aborting make: *** [debian/rules:8: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Any ideas what might have gone wrong? Best, Andrius
Bug#985267: desktop-base: leaves alternatives after purge: /usr/share/desktop-base/active-theme -> /etc/alternatives/desktop-theme
Package: desktop-base Version: 11.0.2 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging The leftover files are actually alternatives that were installed by the package but have not been properly removed. While there is ongoing discussion how to remove alternatives correctly (see https://bugs.debian.org/71621 for details) the following strategy should work for regular cases: * 'postinst configure' always installs the alternative * 'prerm remove' removes the alternative * 'postrm remove' and 'postrm disappear' remove the alternative In all other cases a maintainer script is invoked (e.g. upgrade, deconfigure) the alternatives are not modified to preserve user configuration. Removing the alternative in 'prerm remove' avoids having a dangling link once the actual file gets removed, but 'prerm remove' is not called in all cases (e.g. unpacked but not configured packages or disappearing packages) so the postrm must remove the alternative again (update-alternatives gracefully handles removal of non-existing alternatives). Note that the arguments for adding and removing alternatives differ, for removal it's 'update-alternatives --remove '. Filing this as important as having a piuparts clean archive is a release goal since lenny. >From the attached log (scroll to the bottom...): 0m37.3s INFO: Warning: Package purging left files on system: /etc/alternatives/desktop-theme -> /usr/share/desktop-base/futureprototype-theme not owned /usr/share/desktop-base/ owned by: desktop-base /usr/share/desktop-base/active-theme -> /etc/alternatives/desktop-theme not owned cheers, Andreas desktop-base_11.0.2.log.gz Description: application/gzip
Bug#985266: ITP: golang-github-huandu-go-sqlbuilder -- A flexible and powerful SQL string builder library plus a zero-config ORM.
Package: wnpp
Severity: wishlist
Owner: Thola Team
* Package name: golang-github-huandu-go-sqlbuilder
Version : 1.12.0-1
Upstream Author : Huan Du
* URL : https://github.com/huandu/go-sqlbuilder
* License : Expat
Programming Lang: Go
Description : A flexible and powerful SQL string builder library plus a
zero-config ORM.
SQL builder for Go Go (https://github.com/huandu/go-sqlbuilder/actions)
GoDoc (https://pkg.go.dev/github.com/huandu/go-sqlbuilder) Go Report
(https://goreportcard.com/report/github.com/huandu/go-sqlbuilder) Coverage
Status (https://coveralls.io/github/huandu/go-sqlbuilder?branch=master)
• Install (#install)• Usage (#usage) • Basic
usage (#basic-usage)• Pre-defined SQL builders
(#pre-defined-sql-builders)• Build SQL for MySQL, PostgreSQL or
SQLite (#build-sql-for-mysql--postgresql-or-sqlite)• Using Struct
as a light weight ORM (#using--struct--as-a-light-weight-orm)•
Nested SQL (#nested-sql)• Use sql.Named in a builder
(#use--sqlnamed--in-a-builder)• Argument modifiers
(#argument-modifiers)• Freestyle builder (#freestyle-builder)• Using
special syntax to build SQL (#using-special-syntax-to-build-sql)•
Interpolate args in the sql (#interpolate--args--in-the--sql-)• FAQ
(#faq) • What's the difference between this package and squirrel
(#what-s-the-difference-between-this-package-and--squirrel-)• License
(#license) Package sqlbuilder provides a set of flexible and powerful
SQL string builders. The only goal of this package is to build SQL
string with arguments which can be used in DB#Query or DB#Exec defined
in package database/sql. Install Use go get to install this package.
.
shell go get github.com/huandu/go-sqlbuilder
.
UsageBasic usage We can build a SQL really quick with this package.
.
```go sql := sqlbuilder.Select("id", "name").From("demo.user").
Where("status = 1").Limit(10). String()
.
fmt.Println(sql)
.
// Output: // SELECT id, name FROM demo.user WHERE status = 1 LIMIT 10 ```
.
In the most cases, we need to escape all input from user. In this case,
create a builder before starting.
.
```go sb := sqlbuilder.NewSelectBuilder()
.
sb.Select("id", "name", sb.As("COUNT(*)", "c")) sb.From("user")
sb.Where(sb.In("status", 1, 2, 5))
.
sql, args := sb.Build() fmt.Println(sql) fmt.Println(args)
.
// Output: // SELECT id, name, COUNT(*) AS c FROM user WHERE
status IN (?, ?, ?) // [1 2 5] ``` Pre-defined SQL builders
Following builders are implemented right now. API document
and examples are provided in the godoc document. • Struct
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Struct):
Builder factory for a struct.• CreateTableBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#CreateTableBuilder):
Builder for CREATE TABLE.• SelectBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#SelectBuilder):
Builder for SELECT.• InsertBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#InsertBuilder):
Builder for INSERT.• UpdateBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#UpdateBuilder):
Builder for UPDATE.• DeleteBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#DeleteBuilder):
Builder for DELETE.• UnionBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#UnionBuilder):
Builder for UNION and UNION ALL.• Buildf
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Buildf):
Freestyle builder using fmt.Sprintf-like syntax.• Build
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Build): Advanced
freestyle builder using special syntax defined in Args#Compile
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Args.Compile).•
BuildNamed
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#BuildNamed): Advanced
freestyle builder using ${key} to refer the value of a map by key.
There is a method SQL(sql string) implemented by all statement builders
like SelectBuilder. We can use this method to insert any arbitrary SQL
fragment when building a SQL. It's quite useful to build SQL containing
non-standard syntax supported by a OLTP or OLAP system.
.
``go // Build a SQL to create a HIVE table. sql :=
sqlbuilder.CreateTable("users").
SQL("PARTITION BY (year)"). SQL("AS"). SQL(
sqlbuilder.Select("columns[0] id", "columns[1] name", "columns[2]
year").
From("all-users.csv`"). Limit(100). String(),
). String()
.
fmt.Println(sql)
.
// Output: // CREATE TABLE users PARTITION BY (year) AS SELECT columns[0]
id, columns[1] name, columns[2] year FROM all-users.csv LIMIT 100 ```
.
To learn how to use builders, check out examples on GoDoc
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#pkg-examples).
Build SQL for MySQL, PostgreSQL or SQLite Parameter markers are different
in MySQL, PostgreSQL and SQLite. This package provides some methods to
set the type of markers (we call it "flavor") in all builders.
.
By default, all builders uses DefaultFlavor to build SQL. The default
Bug#985268: ITP: golang-github-huandu-go-sqlbuilder -- A flexible and powerful SQL string builder library plus a zero-config ORM.
Package: wnpp
Severity: wishlist
Owner: deb...@thola.io
* Package name: golang-github-huandu-go-sqlbuilder
Version : 1.12.0-1
Upstream Author : Huan Du
* URL : https://github.com/huandu/go-sqlbuilder
* License : Expat
Programming Lang: Go
Description : A flexible and powerful SQL string builder library plus a
zero-config ORM.
SQL builder for Go Go (https://github.com/huandu/go-sqlbuilder/actions)
GoDoc (https://pkg.go.dev/github.com/huandu/go-sqlbuilder) Go Report
(https://goreportcard.com/report/github.com/huandu/go-sqlbuilder) Coverage
Status (https://coveralls.io/github/huandu/go-sqlbuilder?branch=master)
• Install (#install)• Usage (#usage) • Basic
usage (#basic-usage)• Pre-defined SQL builders
(#pre-defined-sql-builders)• Build SQL for MySQL, PostgreSQL or
SQLite (#build-sql-for-mysql--postgresql-or-sqlite)• Using Struct
as a light weight ORM (#using--struct--as-a-light-weight-orm)•
Nested SQL (#nested-sql)• Use sql.Named in a builder
(#use--sqlnamed--in-a-builder)• Argument modifiers
(#argument-modifiers)• Freestyle builder (#freestyle-builder)• Using
special syntax to build SQL (#using-special-syntax-to-build-sql)•
Interpolate args in the sql (#interpolate--args--in-the--sql-)• FAQ
(#faq) • What's the difference between this package and squirrel
(#what-s-the-difference-between-this-package-and--squirrel-)• License
(#license) Package sqlbuilder provides a set of flexible and powerful
SQL string builders. The only goal of this package is to build SQL
string with arguments which can be used in DB#Query or DB#Exec defined
in package database/sql. Install Use go get to install this package.
.
shell go get github.com/huandu/go-sqlbuilder
.
UsageBasic usage We can build a SQL really quick with this package.
.
```go sql := sqlbuilder.Select("id", "name").From("demo.user").
Where("status = 1").Limit(10). String()
.
fmt.Println(sql)
.
// Output: // SELECT id, name FROM demo.user WHERE status = 1 LIMIT 10 ```
.
In the most cases, we need to escape all input from user. In this case,
create a builder before starting.
.
```go sb := sqlbuilder.NewSelectBuilder()
.
sb.Select("id", "name", sb.As("COUNT(*)", "c")) sb.From("user")
sb.Where(sb.In("status", 1, 2, 5))
.
sql, args := sb.Build() fmt.Println(sql) fmt.Println(args)
.
// Output: // SELECT id, name, COUNT(*) AS c FROM user WHERE
status IN (?, ?, ?) // [1 2 5] ``` Pre-defined SQL builders
Following builders are implemented right now. API document
and examples are provided in the godoc document. • Struct
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Struct):
Builder factory for a struct.• CreateTableBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#CreateTableBuilder):
Builder for CREATE TABLE.• SelectBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#SelectBuilder):
Builder for SELECT.• InsertBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#InsertBuilder):
Builder for INSERT.• UpdateBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#UpdateBuilder):
Builder for UPDATE.• DeleteBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#DeleteBuilder):
Builder for DELETE.• UnionBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#UnionBuilder):
Builder for UNION and UNION ALL.• Buildf
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Buildf):
Freestyle builder using fmt.Sprintf-like syntax.• Build
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Build): Advanced
freestyle builder using special syntax defined in Args#Compile
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Args.Compile).•
BuildNamed
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#BuildNamed): Advanced
freestyle builder using ${key} to refer the value of a map by key.
There is a method SQL(sql string) implemented by all statement builders
like SelectBuilder. We can use this method to insert any arbitrary SQL
fragment when building a SQL. It's quite useful to build SQL containing
non-standard syntax supported by a OLTP or OLAP system.
.
``go // Build a SQL to create a HIVE table. sql :=
sqlbuilder.CreateTable("users").
SQL("PARTITION BY (year)"). SQL("AS"). SQL(
sqlbuilder.Select("columns[0] id", "columns[1] name", "columns[2]
year").
From("all-users.csv`"). Limit(100). String(),
). String()
.
fmt.Println(sql)
.
// Output: // CREATE TABLE users PARTITION BY (year) AS SELECT columns[0]
id, columns[1] name, columns[2] year FROM all-users.csv LIMIT 100 ```
.
To learn how to use builders, check out examples on GoDoc
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#pkg-examples).
Build SQL for MySQL, PostgreSQL or SQLite Parameter markers are different
in MySQL, PostgreSQL and SQLite. This package provides some methods to
set the type of markers (we call it "flavor") in all builders.
.
By default, all builders uses DefaultFlavor to build SQL. The
Bug#985224: unblock: rheolef/ 7.1-6
Dear Boyuan Yang, Many thanks for your fast reply and your fix to the Debian files of the Rheolef package. Are these changes merged now in the master branch of the GIT repository of the debianization of Rheolef ? https://salsa.debian.org/science-team/rheolef Many thanks for your help, Pierre Boyuan Yang a écrit : Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pierre.saram...@imag.fr debian-scie...@lists.debian.org Please unblock package rheolef [ Reason ] The current version of rheolef in Testing has piuparts error (Buster2Bullseye, missing Breaks+Conflicts) as shown in https://bugs.debian.org/984529 . The current version in Sid targets on fixing this RC bug. [ Impact ] If the bug is not fixed, the upgrade from Debian 10 to Debian 11 will fail when both rheolef and librheolef-dev are installed. [ Tests ] Piuparts test failed for package in Testing but succeeded for package in Sid. See: https://piuparts.debian.org/sid/source/r/rheolef.html [ Risks ] No risk expected. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing unblock rheolef/ 7.1-6 -- Soutenez la sécurité sociale ! Signez la pétition pour l'hôpital public : https://confinesmobilises.wesign.it
Bug#985265: psgml: modifies shipped files: /usr/share/emacs/site-lisp/psgml/psgml-init.el
Package: psgml Version: 1.4.0-10 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies files it has shipped. >From the attached log (scroll to the bottom...): 1m16.0s ERROR: FAIL: debsums reports modifications inside the chroot: /usr/share/emacs/site-lisp/psgml/psgml-init.el The modified version of the file is actually an empty file. This seems to be limited to tests with --install-recommends enabled or upgrades from buster. /usr/lib/emacsen-common/packages/install/psgml contains the following code which is the likely culprit. sed -e "s|=F|/usr/share/$FLAVOUR/site-lisp/$PACKAGE|" \ $STARTFILE > $ELDIR/$STARTFILE I do not know anything about emacs packaging, no idea what would be correct. cheers, Andreas psgml_1.4.0-10.log.gz Description: application/gzip
Bug#985158: [pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options
Hi, On Monday 15 March 2021 08:56:36 CET Christoph Biedl wrote: > > > Point is, the legacy file ~/.gnupg/options is still being used in > > > surprisingly many applications, also in documentation: Sorry, but a quick look at the codesearch you linked shows it is not used anywhere except in some outdated documentation or syntax highlighting. Even https://sources.debian.org/src/samhain/4.1.4-2/scripts/samhainadmin.pl.in/? hl=66#L66 which looked from the codesearch as the most promising candidate uses gpg.conf preferredly. > For *after* the release, everything will be possible. My intent is to > keep impact for the current release low. I am using GnuPG since 2006 and I was not even aware that .gnupg/options was a thing before this thread. > My preferred solution was to restore the old behaviour for a limited > time, i.e. parsing the legacy config file, plus emitting that warning. > This will give everybody a chance to adjust their configuration. I think this is an overraction. I cannot imagine that more then a handful of users are affected by this change of ignoring such an historic file. Also those are options, this is nothing security critical in my opinion. Options and option defaults change regularly from one debian release the next. Best Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf. VR 11482 Düsseldorf Vorstand: W.Koch, B.Reiter, A.HeineckeMail: bo...@gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 signature.asc Description: This is a digitally signed message part.
Bug#985121: linux-image-5.10.0-4-rt-arm64: KMS seems broken in vc4.ko
Hi, On 15/03/21 at 09:07 +0900, Ryutaroh Matsumoto wrote: > Hi Lucas, > > > According to strace, it fails because /dev/dri does not exist. > > When vc4.ko is not loaded, /dev/dri does not exist. > If vc4.ko is loaded, /dev/dri exists. Could you make sure that > vc4.ko is loaded by "lsmod | fgrep vc4"? > vc4.ko was disabled at Debian kernel 5.10.9. > Other Debian 5.10.? kernel packages have vc4.ko. Right, sorry, I was testing with the wrong kernel. > When vc4.ko is loaded, kmscube fails as: > > $ kmscube > Using display 0xe087a150 with EGL version 1.4 > === > EGL information: > version: "1.4" > vendor: "Mesa Project" > client extensions: "EGL_EXT_device_base EGL_EXT_device_enumeration > EGL_EXT_device_query EGL_EXT_platform_base > EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug > EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland > EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_gbm > EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless" > display extensions: "EGL_ANDROID_blob_cache EGL_EXT_buffer_age > EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers > EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context > EGL_KHR_create_context_no_error EGL_KHR_fence_sync > EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace > EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image > EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image > EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context > EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float > EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_image_dma_buf_export > EGL_MESA_query_driver " > === > OpenGL ES 2.x information: > version: "OpenGL ES 3.2 Mesa 20.3.4" > shading language version: "OpenGL ES GLSL ES 3.20" > vendor: "Mesa/X.org" > renderer: "llvmpipe (LLVM 11.0.1, 128 bits)" > extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays > GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 > GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA > GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint > GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 > GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D > GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float > GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float > GL_EXT_draw_instanced GL_EXT_texture_sRGB_decode GL_OES_EGL_image > GL_OES_depth_texture GL_OES_packed_depth_stencil > GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render > GL_OES_get_program_binary GL_APPLE_texture_max_level > GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth > GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync > GL_OES_vertex_array_object GL_OES_viewport_array > GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 > GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean > GL_EXT_robustness GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers > GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil > GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug > GL_KHR_robustness GL_KHR_texture_compression_astc_ldr > GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map > GL_OES_required_internalformat GL_OES_surfaceless_context > GL_EXT_color_buffer_float GL_EXT_sRGB_write_control > GL_EXT_separate_shader_objects GL_EXT_shader_group_vote > GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix > GL_EXT_tessellation_point_size GL_EXT_tessellation_shader > GL_ANDROID_extension_pack_es31a GL_EXT_base_instance > GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image > GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex > GL_EXT_gpu_shader5 GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box > GL_EXT_render_snorm GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp > GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_EXT_texture_norm16 > GL_EXT_texture_view GL_KHR_blend_equation_advanced > GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior > GL_NV_image_formats GL_OES_copy_image GL_OES_draw_buffers_indexed > GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 > GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables > GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation > GL_OES_tessellation_point_size GL_OES_tessellation_shader > GL_OES_texture_border_clamp GL_OES_texture_buffer > GL_OES_texture_cube_map_array GL_OES_texture_stencil8 > GL_OES_texture_storage_multisample_2d_array GL_OES_texture_view > GL_EXT_blend_func_extended GL_EXT_buffer_storage GL_EXT_float_blend > GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_KHR_no_error >
Bug#985260: backintime-qt: cron jobs error not mailed to user
Package: backintime-qt Version: 1.2.1-2 Severity: normal X-Debbugs-Cc: none, Francesco Potortì With the default settings, when a cron job encounters a syntax error in the user callback, the error is reported in the system logs, but no mail is sent to the user. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (101, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages backintime-qt depends on: ii backintime-common1.2.1-2 ii libnotify-bin0.7.9-3 ii policykit-1 0.105-30 ii python3 3.9.2-2 ii python3-dbus.mainloop.pyqt5 5.15.2+dfsg-3 ii python3-pyqt55.15.2+dfsg-3 ii x11-utils7.7+5 Versions of packages backintime-qt recommends: ii python3-secretstorage 3.3.1-1 Versions of packages backintime-qt suggests: ii meld 3.20.2-2 -- no debconf information
Bug#985254: openafs-modules-dkms: Fails to build on -rt / non-HIGHMEM kernels
Package: openafs-modules-dkms Version: 1.8.6-5 Followup-For: Bug #985254 X-Debbugs-Cc: witold.bary...@gmail.com Actually after digging more, it is not due to HIGHMEM. In fact the kmap_atomic takes single argument since about kernel 3.13 on all configurations. The issue actually is somewhere else. In config.log I found this: The module compiles, however it doesn't link into .ko file: FATAL: modpost: GPL-incompatible module conftest.ko uses GPL-only symbol 'migrate_disable' And that causes configure to think that the function is not one-argument.
Bug#985254: openafs-modules-dkms: Fails to build on -rt / non-HIGHMEM kernels
Package: openafs-modules-dkms Version: 1.8.6-5 Severity: normal X-Debbugs-Cc: witold.bary...@gmail.com I am pretty sure this is know issue (I was expiriencing it for probably 2 years or more), but I didn't found any open issues to track this problem. ... checking whether kmap_atomic takes no km_type argument... no ... ... Building in directory: MODLOAD-5.10.0-4-rt-amd64-SP make[2]: Entering directory '/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP' ... ... CC [M] /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.o /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c: In function ‘afs_bypass_copy_page’: /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:311:31: error: ‘KM_USER0’ undeclared (first use in this function) 311 | address = kmap_atomic(pp, KM_USER0); | ^~~~ /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:311:31: note: each undeclared identifier is reported only once for each function it appears in /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:311:15: error: too many arguments to function ‘kmap_atomic’ 311 | address = kmap_atomic(pp, KM_USER0); | ^~~ In file included from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem.h:14, from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/pagemap.h:11, from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/blkdev.h:14, from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/backing-dev.h:15, from /var/lib/dkms/openafs/1.8.6/build/src/afs/sysincludes.h:126, from /var/lib/dkms/openafs/1.8.6/build/src/afs/afs_bypasscache.h:67, from /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:64: /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem-internal.h:179:21: note: declared here 179 | static inline void *kmap_atomic(struct page *page) | ^~~ /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:321:36: error: macro "kunmap_atomic" passed 2 arguments, but takes just 1 321 | kunmap_atomic(address, KM_USER0); |^ In file included from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem.h:14, from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/pagemap.h:11, from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/blkdev.h:14, from /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/backing-dev.h:15, from /var/lib/dkms/openafs/1.8.6/build/src/afs/sysincludes.h:126, from /var/lib/dkms/openafs/1.8.6/build/src/afs/afs_bypasscache.h:67, from /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:64: /usr/src/linux-headers-5.10.0-4-common-rt/include/linux/highmem-internal.h:210: note: macro "kunmap_atomic" defined here 210 | #define kunmap_atomic(__addr) \ | /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.c:321:5: error: ‘kunmap_atomic’ undeclared (first use in this function); did you mean ‘kmap_atomic’? 321 | kunmap_atomic(address, KM_USER0); | ^ | kmap_atomic make[5]: *** [/usr/src/linux-headers-5.10.0-4-common-rt/scripts/Makefile.build:284: /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP/afs_bypasscache.o] Error 1 make[4]: *** [/usr/src/linux-headers-5.10.0-4-common-rt/Makefile:1813: /var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP] Error 2 make[3]: *** [/usr/src/linux-headers-5.10.0-4-common-rt/Makefile:185: __sub-make] Error 2 make[3]: Leaving directory '/usr/src/linux-headers-5.10.0-4-rt-amd64' FAILURE: make exit code 2 make[2]: *** [Makefile.afs:279: openafs.ko] Error 1 make[2]: Leaving directory '/var/lib/dkms/openafs/1.8.6/build/src/libafs/MODLOAD-5.10.0-4-rt-amd64-SP' make[1]: *** [Makefile:186: linux_compdirs] Error 2 make[1]: Leaving directory '/var/lib/dkms/openafs/1.8.6/build/src/libafs' make: *** [Makefile:15: all] Error 2 The upstream code, as well the one shipped in Debian -dkms package, does have provisions to detect this issue, and work, but it doesn't. Here is a relevant part: #if !defined(UKERNEL) # if defined(KMAP_ATOMIC_TAKES_NO_KM_TYPE) address = kmap_atomic(pp); # else address = kmap_atomic(pp, KM_USER0); # endif #else address = pp; #endif memcpy(address + pageoff, (char *)(rxiov[iovno].iov_base) + iovoff, dolen); #if !defined(UKERNEL) # if
Bug#985274: unblock: hwloc-contrib/2.4.1+dfsg-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package hwloc-contrib [ Reason ] hwloc-contrib currently FTBFS due to #984984 : nvidia-alternative fixed providing libnvidia-ml.so, and thus hwloc-contrib is now able to build its nvml plugin but dh_missing complains that it was not configured to. In the hwloc-contrib/2.4.1+dfsg-2 upload, I re-enabled installing the nvml plugin, as the attached patch shows. [ Impact ] Without the nvml plugin, it is harder for hwloc-based applications to determine the locality of GPUs in the system, and thus to optimize data transfers and get efficient execution. [ Tests ] I have tested it on a system that has GPUs, the nvml location is correct. [ Risks ] The code change is trivial :) The consequence for systems without a GPU is just an nvmlInit() call that will report that there is no nvml device. For systems with a GPU, the nvml plugin just gets information from libnvidia-ml and stores it for applications that would want it. Alternatively, we could mark the nvml plugin as not-installed. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing unblock hwloc-contrib/2.4.1+dfsg-2 diff -Nru hwloc-contrib-2.4.1+dfsg/debian/changelog hwloc-contrib-2.4.1+dfsg/debian/changelog --- hwloc-contrib-2.4.1+dfsg/debian/changelog 2021-02-22 18:21:18.0 +0100 +++ hwloc-contrib-2.4.1+dfsg/debian/changelog 2021-03-11 16:01:54.0 +0100 @@ -1,3 +1,10 @@ +hwloc-contrib (2.4.1+dfsg-2) unstable; urgency=medium + + * libhwloc-contrib-plugins.install: Install the nvml plugin again +(Closes: Bug#984984) + + -- Samuel Thibault Thu, 11 Mar 2021 16:01:54 +0100 + hwloc-contrib (2.4.1+dfsg-1) unstable; urgency=medium * New upstream bugfix release. diff -Nru hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install --- hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install 2021-02-22 18:21:18.0 +0100 +++ hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install 2021-03-11 16:01:54.0 +0100 @@ -1 +1,2 @@ usr/lib/*/hwloc/hwloc_cuda.so +usr/lib/*/hwloc/hwloc_nvml.so
Bug#985276: unblock: fsm-lite/1.0-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org
Please unblock package fsm-lite
(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)
[ Reason ]
The version of fsm-lite i.e. 1.0-4 uses -msse4.2 flag for compiling on
amd64. This is a baseline violation.
Correspondingly, a RC bug had been reported as #985061 and fixed in version
1.0-5
as can be seen here[1]
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985061
[ Impact ]
The program would crash for users with Illegal instruction error on
earlier versions of amd64 CPU, which do not support SSE4.2 instructions.
[ Tests ]
I do not have access to an older CPU to test this very particular
change, but it now does not use sse4.2 instrcutions for compiling, that
should mitigate the issue.
I installed the fixed version regardless, and it looks good for basic
tweaking that I did. (This package does not have autopkgtests yet, so
complete validity is a bit difficult to ascertain) For sure, there is no
"major" changes in the two versions in unstable and testing.
[ Risks ]
This is a leaf package and is also a non key package. There are no huge
changes. Low risk, I'd say
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock fsm-lite/1.0-5
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru fsm-lite-1.0/debian/changelog fsm-lite-1.0/debian/changelog
--- fsm-lite-1.0/debian/changelog 2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/changelog 2021-03-12 20:22:36.0 +0530
@@ -1,3 +1,13 @@
+fsm-lite (1.0-5) unstable; urgency=medium
+
+ * Team upload.
+ * debian/rules: Don't pass -msse4.2, ever. Closes: #985061
+ * Standards-Version: 4.5.1 (routine-update)
+ * watch file standard 4 (routine-update)
+ * debian/upstream/metadata: add GitHub repo
+
+ -- Michael R. Crusoe Fri, 12 Mar 2021 15:52:36 +0100
+
fsm-lite (1.0-4) unstable; urgency=medium
[ Andrius Merkys ]
diff -Nru fsm-lite-1.0/debian/control fsm-lite-1.0/debian/control
--- fsm-lite-1.0/debian/control 2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/control 2021-03-12 20:22:36.0 +0530
@@ -5,7 +5,7 @@
Priority: optional
Build-Depends: debhelper-compat (= 13),
libsdsl-dev
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/med-team/fsm-lite
Vcs-Git: https://salsa.debian.org/med-team/fsm-lite.git
Homepage: https://github.com/nvalimak/fsm-lite
diff -Nru fsm-lite-1.0/debian/patches/fix_makefile.patch
fsm-lite-1.0/debian/patches/fix_makefile.patch
--- fsm-lite-1.0/debian/patches/fix_makefile.patch 2020-11-10
22:06:49.0 +0530
+++ fsm-lite-1.0/debian/patches/fix_makefile.patch 2021-03-12
20:22:36.0 +0530
@@ -1,17 +1,16 @@
Description: Support more architectures
Bug-Debian: http://bugs.debian.org/824368
Author: Andreas Tille
-Last-Update: Sun, 15 May 2016 09:04:46 +0200
-
a/Makefile
-+++ b/Makefile
-@@ -1,11 +1,11 @@
+Last-Update: 2021-03-12
+Forwarded: not-needed
+--- fsm-lite.orig/Makefile
fsm-lite/Makefile
+@@ -1,11 +1,10 @@
-SDSL_INSTALL_PREFIX=${HOME}/software
-
-CPPFLAGS=-std=c++11 -I$(SDSL_INSTALL_PREFIX)/include -DNDEBUG -O3 -msse4.2
+CPPFLAGS+=-DNDEBUG
-+CXXFLAGS+=-std=c++11
-+# -O3 -msse4.2
++CXXFLAGS+=-std=c++11 -O3
LIBS=-lsdsl -ldivsufsort -ldivsufsort64
OBJ = configuration.o input_reader.o fsm-lite.o
@@ -21,7 +20,7 @@
test: fsm-lite
./fsm-lite -l test.list -t tmp -v --debug -m 1
-@@ -14,6 +14,6 @@ clean:
+@@ -14,6 +13,6 @@
$(RM) fsm-lite *.o *~
depend:
diff -Nru fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
--- fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
2021-03-12 20:22:36.0 +0530
@@ -1,6 +1,7 @@
Author: Andreas Tille
Last-Update: Fri, 08 Apr 2016 10:01:02 +0200
Description: Upstream hardcodes local path to libsdsl which is removed here
+Forwarded: not-needed
--- a/dependencies.mk
+++ b/dependencies.mk
diff -Nru fsm-lite-1.0/debian/rules fsm-lite-1.0/debian/rules
--- fsm-lite-1.0/debian/rules 2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/rules
Bug#985291: ITP: python-dictknife -- Armyknife of handling dict object
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: python-dictknife Version : 0.13.0 Upstream Author : Podhmo * URL : https://github.com/podhmo/dictknife * License : Expat Programming Lang: Python Description : Armyknife of handling dict object Utility set to handle Python dicts. . Include command line tools as well. This package is a dependency of swagger-marshmallow-codegen (ITP: #985275).
Bug#985292: materia-gtk-theme: unhandled symlink to directory conversion: /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets
Package: materia-gtk-theme Version: 20200916-0.1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster -> bullseye For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 1m8.4s ERROR: installs objects over existing directory symlinks: /usr/share/themes/Materia-compact/gtk-3.0/assets/scale-horz-marks-after-slider-dark.png (materia-gtk-theme) != /usr/share/themes/Materia-compact/gtk-assets/scale-horz-marks-after-slider-dark.png (?) /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets /usr/share/themes/Materia-compact/gtk-3.0/assets/scale-horz-marks-after-slider-d...@2.png (materia-gtk-theme) != /usr/share/themes/Materia-compact/gtk-assets/scale-horz-marks-after-slider-d...@2.png (?) /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets /usr/share/themes/Materia-compact/gtk-3.0/assets/scale-horz-marks-after-slider-disabled-dark.png (materia-gtk-theme) != /usr/share/themes/Materia-compact/gtk-assets/scale-horz-marks-after-slider-disabled-dark.png (?) /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets /usr/share/themes/Materia-compact/gtk-3.0/assets/scale-horz-marks-after-slider-disabled-d...@2.png (materia-gtk-theme) != /usr/share/themes/Materia-compact/gtk-assets/scale-horz-marks-after-slider-disabled-d...@2.png (?) /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets /usr/share/themes/Materia-compact/gtk-3.0/assets/scale-horz-marks-after-slider-disabled.png (materia-gtk-theme) != /usr/share/themes/Materia-compact/gtk-assets/scale-horz-marks-after-slider-disabled.png (?) /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets [...] /usr/share/themes/Materia/gtk-3.0/assets/selectionmode-checkbox-unchecked-d...@2.png (materia-gtk-theme) != /usr/share/themes/Materia/gtk-assets/selectionmode-checkbox-unchecked-d...@2.png (?) /usr/share/themes/Materia/gtk-3.0/assets -> ../gtk-assets /usr/share/themes/Materia/gtk-3.0/assets/selectionmode-checkbox-unchecked.png (materia-gtk-theme) != /usr/share/themes/Materia/gtk-assets/selectionmode-checkbox-unchecked.png (?) /usr/share/themes/Materia/gtk-3.0/assets -> ../gtk-assets /usr/share/themes/Materia/gtk-3.0/assets/selectionmode-checkbox-unchec...@2.png (materia-gtk-theme) != /usr/share/themes/Materia/gtk-assets/selectionmode-checkbox-unchec...@2.png (?) /usr/share/themes/Materia/gtk-3.0/assets -> ../gtk-assets cheers, Andreas materia-gtk-theme_20200916-0.1.log.gz Description: application/gzip
Bug#981066: aerc: Cannot Render HTML Emails After Latest w3m Update in bullseye
Control: retitle -1 aerc: cannot display either plaintext or HTML emails
Control: tags -1 + patch
On 2021-01-26 at 07:50 +1030, Solya. Reka wrote:
> After I did a apt upgrade today (which upgraded w3m from 0.5.3+git20210102-1
> to
> 0.5.3+git20210102-2), I am no longer able to display either plaintext or HTML
> emails. The message viewer simply display a empty screen instead of email
> content.
It seems not relate to w3m. On my sid amd64 environment, with the
fresh installed aerc 0.3.0-2+b2, all the contents of the emails are
empty even if text/html filter is disabled (by default) in
~/.config/aerc/aerc.conf. Even `:pipe less` and `:pipe cat` fail.
I've skimmed throw the upstream git log, and found the related commit.
See the attached patch against aerc 0.3.0-2.
Thanks,
--
Tatsuya Kinoshita
commit ce90d8fb9beabe991e27740c464f95ac86d74b20
Author: Tatsuya Kinoshita
Date: Mon Mar 15 19:07:39 2021 +0900
New patch fix-empty-content.patch to display email body (Closes: #981066)
diff --git a/debian/patches/fix-empty-content.patch b/debian/patches/fix-empty-content.patch
new file mode 100644
index 000..65412d6
--- /dev/null
+++ b/debian/patches/fix-empty-content.patch
@@ -0,0 +1,29 @@
+Subject: Use stdout as controlling terminal
+Origin: backport, https://git.sr.ht/~sircmpwn/aerc/commit/dc281e46d2aceaab6a7b7a290f9af89fef46159d
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983165
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981066
+
+Soves an issue with go1.15 not letting ctty be a parent. See
+https://github.com/creack/pty/pull/97 for more details.
+
+diff --git a/widgets/terminal.go b/widgets/terminal.go
+index 8fc38ce..77da71e 100644
+--- a/widgets/terminal.go
b/widgets/terminal.go
+@@ -4,6 +4,7 @@ import (
+ "os"
+ "os/exec"
+ "sync"
++ "syscall"
+
+ "git.sr.ht/~sircmpwn/aerc/lib/ui"
+
+@@ -237,7 +238,7 @@ func (term *Terminal) Draw(ctx *ui.Context) {
+
+ if term.pty == nil {
+ term.vterm.SetSize(ctx.Height(), ctx.Width())
+- tty, err := pty.StartWithSize(term.cmd, )
++ tty, err := pty.StartWithAttrs(term.cmd, , {Setsid: true, Setctty: true, Ctty: 1})
+ term.pty = tty
+ if err != nil {
+ term.Close(err)
diff --git a/debian/patches/series b/debian/patches/series
index 3b5d2bb..6e8232a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ use-creack-pty.diff
fix-go-maildir-usage.diff
temp-disable-beep.diff
fix-installation-directories.diff
+fix-empty-content.patch
pgpWE7LHGexzs.pgp
Description: PGP signature
Bug#985273: libebitdo-dev: uninstallable in stretch
Package: libebitdo-dev Version: 0.7.4-2+deb9u1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: close -1 Hi, during a test with piuparts I noticed your package is no longer installable in stretch. libebitdo-dev 0.7.4-2+deb9u1 is a cruft package still available in stetch/updates, but it is no longer built by src:fwupd 0.8.3-1 in stretch. The following packages have unmet dependencies: libebitdo-dev : Depends: libdfu1 (= 0.7.4-2+deb9u1) but 0.8.3-1 is to be installed Cheers, Andreas
Bug#985269: [Debichem-devel] Bug#985269: libint1: ships broken library symlinks: /usr/lib/lib*-stable.so.1 -> lib*.so.1
Hi,
On Mon, Mar 15, 2021 at 10:40:09AM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
Thanks for the report.
> From the attached log (scroll to the bottom...):
>
> libint1: MISSING OBJECT /usr/lib/libderiv-stable.so.1
> libint1: MISSING OBJECT /usr/lib/libint-stable.so.1
> libint1: MISSING OBJECT /usr/lib/libr12-stable.so.1
Those are legacy symlinks. I am not sure they are still needed, but
probably now isn't the time to remove them either.
> The dangling symlinks get "cleaned up" by ldconfig.
>
> The package ships the following libraries and symlinks:
>
> -rw-r--r-- root/root 20421064 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libderiv.so.1.0.0
> -rw-r--r-- root/root 9215552 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libint.so.1.0.0
> -rw-r--r-- root/root 9816208 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libr12.so.1.0.0
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/libderiv-stable.so.1 -> libderiv.so.1
> lrwxrwxrwx root/root 0 2021-03-04 15:25 ./usr/lib/libint-stable.so.1
> -> libint.so.1
> lrwxrwxrwx root/root 0 2021-03-04 15:25 ./usr/lib/libr12-stable.so.1
> -> libr12.so.1
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libderiv.so.1 -> libderiv.so.1.0.0
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libint.so.1 -> libint.so.1.0.0
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libr12.so.1 -> libr12.so.1.0.0
>
> Do you need to move the lib*-stable.so.1 symlinks to
> /usr/lib/${DEB_HOST_MULTIARCH} ?
I guess dh_link can't cope with multiarch, so we will have to to the
symlinking in an install override, will look into it.
Michael
Bug#985270: Resignation + Call for votes for new Chair
> ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Margarita Manterola > B : David Bremner > C : Niko Tyni > D : Gunnar Wolf > E : Simon McVittie > F : Sean Whitton > G : Elana Hashman > H : Christoph Berg > > ===END=== I vote A > B = C = D = E = F = G > H Christoph signature.asc Description: PGP signature
Bug#985275: ITP: swagger-marshmallow-codegen -- Generate Marshmallow's schema from Swagger/OpenAPI 3.0 definitions
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: swagger-marshmallow-codegen Version : 0.6.4 Upstream Author : Podhmo * URL : https://github.com/podhmo/swagger-marshmallow-codegen * License : Expat Programming Lang: Python Description : Generate Marshmallow's schema from Swagger/OpenAPI 3.0 definitions Command line utility converting Swagger or OpenAPI 3.0 YAML schemas into Marshmallow schemas. . Concepts: . * Code generation is better than meta programming * Don't touch me (generated code) if you can This module will be maintained withing the Debian Python Module Team.
Bug#958628: postgresql-common: Declares alternative Build-Depends on deprecated dh-systemd which is going away
> your package postgresql-common declares an alternative build dependency on > dh-systemd. > dh-systemd was merged into debhelper in version 9.20160709 [1] and since > stretch, dh-systemd is an empty transitional package. > > For bullseye we intend to drop this empty transitional package. > > Please consider dropping the "| dh-systemd" alternative Build-Depends in one > of > your next uploads. It is no longer required (not even for backports) and is > only confusing. I believe it is still required for backports to Ubuntu xenial, but luckily that is going away soon. Christoph
Bug#958628: postgresql-common: Declares alternative Build-Depends on deprecated dh-systemd which is going away
Am 15.03.21 um 13:10 schrieb Christoph Berg: your package postgresql-common declares an alternative build dependency on dh-systemd. dh-systemd was merged into debhelper in version 9.20160709 [1] and since stretch, dh-systemd is an empty transitional package. For bullseye we intend to drop this empty transitional package. Please consider dropping the "| dh-systemd" alternative Build-Depends in one of your next uploads. It is no longer required (not even for backports) and is only confusing. I believe it is still required for backports to Ubuntu xenial, but luckily that is going away soon. xenial-backports provides a recent enough debhelper [1]. And since this is only a build dependency, I think it's fine to just pull debhelper from there. Regards, Michael [1] https://packages.ubuntu.com/xenial-backports/debhelper OpenPGP_signature Description: OpenPGP digital signature
Bug#985285: unblock: mutter/3.38.3-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mutter [ Reason ] * Update from upstream gnome-3-38 branch to pick up bug fixes backported from GNOME 40 development. I was hoping for a 3.38.4 release sometime around our freeze date, but that hasn't happened. * Test this package in its (superficial) autopkgtest, rather than testing leftover GNOME 3.36 packages with a previous SONAME [ Impact ] These upstream bugs affect bullseye and are fixed here: * A crash when clicking below the window title bar in certain GTK themes * X11 applications weren't reliably redrawn when they should be * Incorrect focus handling under X11, when minimizing a window that should have resulted in focus passing to an AWT/Swing Java application * A significant performance regression on machines that don't support hardware acceleration, such as some NVIDIA GPUs with nouveau (a code change that was meant to make this faster actually made it slower, and is disabled in this version by guarding it with an environment variable) In addition, Marco Trevisan fixed the superficial autopkgtest for the -dev package to use the correct SONAME for this version of mutter. Previously, we were testing "cruft" packages left over from GNOME 3.36. [ Tests ] I've been using GNOME day-to-day in Wayland mode on my Intel-based laptop. I've also tried it in X11 mode on the same laptop, and in X11 mode on a desktop with the NVIDIA proprietary drivers, with no regressions observed. [ Risks ] mutter is part of our default desktop compositor (GNOME Shell), so any regressions in it are high-visibility, but so are the bugs we're fixing here. Upstream are generally good about only backporting genuine bug fixes to their stable-branch, and fixing regressions promptly. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock mutter/3.38.3-5 diffstat for mutter-3.38.3 mutter-3.38.3 changelog | 31 ++ patches/clutter-stage-view-Disable-double-buffered-shadow-bufferi.patch | 56 patches/compositor-x11-Notify-the-sync-ring-about-frames-on-updat.patch | 109 + patches/core-Account-for-the-globally-active-input-case.patch | 59 + patches/frame-Fix-crash-when-clicking-below-titlebar-with-broken-.patch | 41 +++ patches/series |6 patches/window-Add-is_focus_async-API.patch | 113 ++ patches/window-actor-x11-Queue-full-actor-redraw-when-redraw-queu.patch | 56 tests/control |4 tests/libmutter-6-dev | 41 --- tests/libmutter-7-dev | 41 +++ 11 files changed, 514 insertions(+), 43 deletions(-) diff -Nru mutter-3.38.3/debian/changelog mutter-3.38.3/debian/changelog --- mutter-3.38.3/debian/changelog 2021-02-23 09:27:54.0 + +++ mutter-3.38.3/debian/changelog 2021-03-10 09:37:00.0 + @@ -1,3 +1,34 @@ +mutter (3.38.3-5) unstable; urgency=medium + + * Team upload + + [ Marco Trevisan (Treviño) ] + * debian/patches: Include a missing commit from upstream gnome-3-38 +branch to fix X11 UI stutters + + -- Simon McVittie Wed, 10 Mar 2021 09:37:00 + + +mutter (3.38.3-4) unstable; urgency=medium + + * Team upload + + [ Marco Trevisan (Treviño) ] + * debian/patches: cherry-pick more upstream gnome-3-38 fixes +- Correctly restore focus to applications that use globally active + input handling, such as AWT/Swing Java apps +- Disable double buffered shadow buffering, which was intended to + improve performance with e.g. llvmpipe but currently makes it worse + * debian/tests: Adapt autopkgtest name and linked library to current soname + * debian/tests/control: Update references to libmutter-7-dev + + [ Simon McVittie ] + * d/patches: Update to commit 3.38.3-26-g30c542ddc from gnome-3-38 branch +- Fix X11 frame timing getting stuck if frames are skipped, resulting + in X11 applications not always being redrawn when they should be +- Fix a crash when clicking below titlebar with broken GTK themes + + -- Simon McVittie Tue, 09 Mar 2021 20:34:42 + + mutter (3.38.3-3) unstable; urgency=medium * Team upload diff -Nru mutter-3.38.3/debian/patches/clutter-stage-view-Disable-double-buffered-shadow-bufferi.patch mutter-3.38.3/debian/patches/clutter-stage-view-Disable-double-buffered-shadow-bufferi.patch --- mutter-3.38.3/debian/patches/clutter-stage-view-Disable-double-buffered-shadow-bufferi.patch 1970-01-01 01:00:00.0 +0100 +++ mutter-3.38.3/debian/patches/clutter-stage-view-Disable-double-buffered-shadow-bufferi.patch
Bug#985286: libbatteries-ocaml-doc: unhandled symlink to directory conversion: /usr/share/doc/libbatteries-ocaml-dev/examples -> ../libbatteries-ocaml-doc/examples
Package: libbatteries-ocaml-doc Version: 3.1.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster -> bullseye For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m38.7s ERROR: installs objects over existing directory symlinks: /usr/share/doc/libbatteries-ocaml-dev/examples/battop.ml (libbatteries-ocaml-doc) != /usr/share/doc/libbatteries-ocaml-doc/examples/battop.ml (?) /usr/share/doc/libbatteries-ocaml-dev/examples -> ../libbatteries-ocaml-doc/examples cheers, Andreas libbatteries-ocaml-doc_3.1.0-1.log.gz Description: application/gzip
Bug#985293: neutron-common: missing Breaks: python3-neutron-fwaas
Package: neutron-common
Version: 2:17.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + python3-neutron-fwaas
Hi,
during a test with piuparts I noticed python3-neutron-fwaas fails to
remove after the upgrade from buster to bullseye.
python3-neutron-fwaas does not exist in bullseye any longer, but does
not get removed during the upgrade. Removing the package after the
upgrade fails because it calls neutron-plugin-manage in a now
unsupported way. At least that's what I conclude from the log.
Adding a (unversioned) Breaks against the package should get it
removed before the incompatible neutron-plugin-manage script gets
unpacked.
>From the attached log (scroll to the bottom...):
Removing python3-neutron-fwaas (1:13.0.1-7) ...
2021-03-13 21:36:47,852 - stevedore.extension - ERROR - Could not load
'firewall': cannot import name 'rpc' from 'neutron.common'
(/usr/lib/python3/dist-packages/neutron/common/__init__.py)
2021-03-13 21:36:47,869 - stevedore.extension - ERROR - Could not load
'firewall_v2': cannot import name '_model_query' from 'neutron.db'
(/usr/lib/python3/dist-packages/neutron/db/__init__.py)
2021-03-13 21:36:47,870 - stevedore.extension - ERROR - Could not load
'neutron.services.firewall.fwaas_plugin.FirewallPlugin': cannot import name
'rpc' from 'neutron.common'
(/usr/lib/python3/dist-packages/neutron/common/__init__.py)
2021-03-13 21:36:47,883 - stevedore.extension - ERROR - Could not load
'fwaas': cannot import name 'rpc' from 'neutron.common'
(/usr/lib/python3/dist-packages/neutron/common/__init__.py)
2021-03-13 21:36:47,886 - stevedore.extension - ERROR - Could not load
'fwaas_v2': cannot import name 'rpc' from 'neutron.common'
(/usr/lib/python3/dist-packages/neutron/common/__init__.py)
2021-03-13 21:36:47,915 - neutron-plugin-manage - ERROR - Could not load
'neutron.fwaas': cannot import name 'rpc' from 'neutron.common'
(/usr/lib/python3/dist-packages/neutron/common/__init__.py)
usage: neutron-plugin-manage disable
[-h]
[--service-plugin
{auto_allocate,conntrack_helper,dummy,flavors,log,loki,metering,network_ip_availability,network_segment_range,ovn-router,placement,port_forwarding,qos,revisions,router,segments,tag,timestamp,trunk}]
[--l3-extension
{conntrack_helper,fip_qos,gateway_ip_qos,port_forwarding,snat_log,fwaas_v2_log}]
{enable,disable}
...
neutron-plugin-manage disable: error: argument --service-plugin: invalid
choice: 'firewall_v2' (choose from 'auto_allocate', 'conntrack_helper',
'dummy', 'flavors', 'log', 'loki', 'metering', 'network_ip_availability',
'network_segment_range', 'ovn-router', 'placement', 'port_forwarding', 'qos',
'revisions', 'router', 'segments', 'tag', 'timestamp', 'trunk')
dpkg: error processing package python3-neutron-fwaas (--remove):
installed python3-neutron-fwaas package pre-removal script subprocess
returned error exit status 2
dpkg: too many errors, stopping
Errors were encountered while processing:
python3-neutron-fwaas
cheers,
Andreas
python3-neutron-fwaas_None.log.gz
Description: application/gzip
Bug#985277: "systemctl reload virtlogd" fails: Cannot disable close-on-exec flag on socket -1: Bad file descriptor
Package: libvirt-daemon Version: 7.0.0-3 Severity: normal I noticed virtlogd in "systemctl --state=failed". It restarted OK, but failed to reload (see attached). I haven't looked yet, but I'm guessing logrotate triggers reload each night? No idea about the EBADF either, maybe a double-close problem. The only remotely interesting thing I'm doing on this host is using ZFS and virtio-fs. Otherwise it's a fairly standard Debian 11 install with a couple of Debian 11 guest VMs, all currently off. I can provide more debugging if needed. cyber@heavy:~$ sudo systemctl restart virtlogd cyber@heavy:~$ sudo systemctl status virtlogd ● virtlogd.service - Virtual machine log manager Loaded: loaded (/lib/systemd/system/virtlogd.service; indirect; vendor preset: enabled) Active: active (running) since Mon 2021-03-15 22:23:47 AEDT; 2s ago TriggeredBy: ● virtlogd-admin.socket ● virtlogd.socket Docs: man:virtlogd(8) https://libvirt.org Main PID: 584609 (virtlogd) Tasks: 1 (limit: 77101) Memory: 1.7M CPU: 15ms CGroup: /system.slice/virtlogd.service └─584609 /usr/sbin/virtlogd Mar 15 22:23:47 heavy systemd[1]: Started Virtual machine log manager. cyber@heavy:~$ sudo systemctl reload virtlogd cyber@heavy:~$ sudo systemctl status virtlogd ● virtlogd.service - Virtual machine log manager Loaded: loaded (/lib/systemd/system/virtlogd.service; indirect; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2021-03-15 22:23:58 AEDT; 1s ago TriggeredBy: ● virtlogd-admin.socket ● virtlogd.socket Docs: man:virtlogd(8) https://libvirt.org Process: 584609 ExecStart=/usr/sbin/virtlogd $VIRTLOGD_ARGS (code=exited, status=9) Process: 585122 ExecReload=/bin/kill -USR1 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 584609 (code=exited, status=9) CPU: 21ms Mar 15 22:23:47 heavy systemd[1]: Started Virtual machine log manager. Mar 15 22:23:58 heavy systemd[1]: Reloading Virtual machine log manager. Mar 15 22:23:58 heavy systemd[1]: Reloaded Virtual machine log manager. Mar 15 22:23:58 heavy virtlogd[584609]: libvirt version: 7.0.0, package: 3 (Andrea Bolognani Fri, 26 Feb 2021 16:46:34 +0100) Mar 15 22:23:58 heavy virtlogd[584609]: hostname: heavy Mar 15 22:23:58 heavy virtlogd[584609]: Cannot disable close-on-exec flag on socket -1: Bad file descriptor Mar 15 22:23:58 heavy systemd[1]: virtlogd.service: Main process exited, code=exited, status=9/n/a Mar 15 22:23:58 heavy systemd[1]: virtlogd.service: Failed with result 'exit-code'.
Bug#985278: ITP: python-evilunit -- Alternative unittests framework for Python
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: python-evilunit Version : 0.2.1 Upstream Author : Podhmo * URL : https://github.com/podhmo/evilunit * License : Expat Programming Lang: Python Description : Alternative unittests framework for Python This package contains a unittests module for Python with the following features: . * Shortcuts, * Parameterized, * Nested. This module will be maintained withing the Debian Python Module Team. This package is a dependency of python-prestring which is a dependency of swagger-marshmallow-codegen (ITP: #985275).
Bug#985288: chai: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Package: chai Version: 4.2.0+ds+~4.2.14-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster -> bullseye For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m40.7s ERROR: FAIL: silently overwrites files via directory symlinks: /usr/share/doc/chai/History.md.gz (chai) != /usr/share/doc/libjs-chai/History.md.gz (libjs-chai) /usr/share/doc/chai -> libjs-chai /usr/share/doc/chai/changelog.Debian.gz (chai) != /usr/share/doc/libjs-chai/changelog.Debian.gz (libjs-chai) /usr/share/doc/chai -> libjs-chai /usr/share/doc/chai/changelog.gz (chai) != /usr/share/doc/libjs-chai/changelog.gz (libjs-chai) /usr/share/doc/chai -> libjs-chai /usr/share/doc/chai/copyright (chai) != /usr/share/doc/libjs-chai/copyright (libjs-chai) /usr/share/doc/chai -> libjs-chai cheers, Andreas chai_4.2.0+ds+~4.2.14-3.log.gz Description: application/gzip
Bug#985272: ITP: golang-github-huandu-go-assert -- Magic assert macros for Go.
Package: wnpp
Severity: wishlist
Owner: deb...@thola.io
* Package name: golang-github-huandu-go-assert
Version : 1.1.5-1
Upstream Author : Huan Du
* URL : https://github.com/huandu/go-assert
* License : Expat
Programming Lang: Go
Description : Magic assert macros for Go.
Package assert - Magic assert macros for Go Go Go Doc
(https://pkg.go.dev/github.com/huandu/go-assert)
.
Package assert provides developer a way to assert expression and output
useful contextual information automatically when a case fails. With this
package, we can focus on writing test code without worrying about how
to print lots of verbose debug information for debug.
.
Here is a quick sample.
.
```go import "github.com/huandu/go-assert"
.
func TestSomething(t *testing.T) {
str := Foo(42) assert.Assert(t, str == "expected")
// This case fails with following message. // // Assertion failed:
// str == "expected" // Referenced variables are assigned
in following statements: // str := Foo(42)
.
} ``` Import Use go get to install this package.
.
shell go get github.com/huandu/go-assert
.
.
Current stable version is v1.*. Old versions tagged by v0.* are obsoleted.
UsageAssertion methods If we just want to use functions like Assert,
Equal or NotEqual, it's recommended to import this package as ..
.
```go import "github.com/huandu/go-assert"
.
func TestSomething(t *testing.T) {
a, b := 1, 2 assert.Assert(t, a > b)
// This case fails with message: // Assertion failed: // a > b
.
}
.
func TestAssertEquality(t *testing.T) {
assert.Equal(t, map[string]int{
"foo": 1, "bar": -2,
}, map[string]int{
"bar": -2, "foo": 1,
})
// This case fails with message: // Assertion failed: // The
value of following expression should equal. // [1] map[string]int{
// "foo": 1, // "bar": -2, // } // [2]
map[string]int{ // "bar": -2, // "foo": 1, //
} // Values: // [1] -> (map[string]int)map[bar:-2 foo:1] //
[2] -> (map[string]int)map[bar:-2 foo:1]
.
} ``` Advanced assertion wrapper: type A If we want more controls on
assertion, it's recommended to wrap t in an A.
.
There are lots of useful assert methods implemented in A. • Assert
(https://godoc.org/github.com/huandu/go-assert#A.Assert)/Eqaul
(https://godoc.org/github.com/huandu/go-assert#A.Equal)/NotEqual
(https://godoc.org/github.com/huandu/go-assert#A.NotEqual):
Basic assertion methods.• NilError
(https://godoc.org/github.com/huandu/go-assert#A.NilError)/NonNilError
(https://godoc.org/github.com/huandu/go-assert#A.NonNilError):
Test if a func/method returns expected error.• Use
(https://godoc.org/github.com/huandu/go-assert#A.Use): Track variables. If
any assert method fails, all variables tracked by A and related in assert
method will be printed out automatically in assertion message. Here is
a sample to demonstrate how to use A#Use to print related variables in
assertion message.
.
```go import "github.com/huandu/go-assert"
.
func TestSomething(t *testing.T) {
a := assert.New(t) v1 := 123 v2 := []string{"wrong", "right"} v3 :=
v2[0] v4 := "not related" a.Use(, , , )
a.Assert(v1 == 123 && v3 == "right")
.
// This case fails with following message. // // Assertion failed:
// v1 == 123 && v3 == "right" // Referenced variables are
assigned in following statements: // v1 := 123 // v3 :=
v2[0] // Related variables: // v1 -> (int)123 // v2 ->
([]string)[wrong right] // v3 -> (string)wrong
.
}
Bug#985270: Resignation + Call for votes for new Chair
Hi! > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Margarita Manterola > B : David Bremner > C : Niko Tyni > D : Gunnar Wolf > E : Simon McVittie > F : Sean Whitton > G : Elana Hashman > H : Christoph Berg > > ===END=== My vote: B > C > F = G > D > E > A > H -- Regards, Marga signature.asc Description: PGP signature
Bug#979765: Kernel panic of linux 5.10.19-1 with VIA Nano L2200 on VX800
As a workaround, I'm passing kernel parameter 'initcall_blacklist=init_hw_perf_events' to disable the Zhaoxin PMU driver. The system boots without panic. Differences in the boot log: [0.00] Linux version 5.10.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.19-1 (2021-03-02) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-4-amd64 root=UUID=b67d3756-ab82-433c-bf15-babec8b88979 ro single initcall_blacklist=init_hw_perf_events console=tty0 console=ttyS0,115200 ... [0.901032] Freeing SMP alternatives memory: 32K [1.018469] smpboot: CPU0: Centaur VIA Nano processor L2200@1600MHz (family: 0x6, model: 0xf, stepping: 0x2) [1.021040] rcu: Hierarchical SRCU implementation. [1.029009] NMI watchdog: Perf NMI watchdog permanently disabled ... Without the parameter, the kernel logs the following (copied from the attached boot log in my previous message): [0.00] Linux version 5.10.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.19-1 (2021-03-02) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-4-amd64 root=UUID=b67d3756-ab82-433c-bf15-babec8b88979 ro single console=tty0 console=ttyS0,115200 ... [0.892088] Freeing SMP alternatives memory: 32K [1.009527] smpboot: CPU0: Centaur VIA Nano processor L2200@1600MHz (family: 0x6, model: 0xf, stepping: 0x2) [1.011855] Performance Events: [1.011858] core: Welcome to zhaoxin pmu! [1.019298] core: Version check pass! [1.023297] ZXC events, zhaoxin PMU driver. [1.027299] ... version:2 [1.031297] ... bit width: 40 [1.035297] ... generic registers: 3 [1.039297] ... value mask: 00ff [1.043297] ... max period: 007f [1.047297] ... fixed-purpose events: 3 [1.051297] ... event mask: 00070007 [1.055663] rcu: Hierarchical SRCU implementation. [1.063822] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. ...
Bug#985255: Systemd initiates fsckd for no apparent reason
Package: systemd Version: 247.3-1 Every few system restarts fsckd runs and fails with the following error message: [TIME] timed out waiting for device /dev/sdb2 I am subsequently dropped into a terminal session (busybox?) There are no problems with the filesystem or the hard disk (SSD) in question. Pressing Ctl-Alt-Del almost always results in a successful reboot. Rarely, the system will halt again with the same error message requiring yet another reboot. In any case, the system eventually boots without error. This problem first appeared on a hard disk that has since been replaced. Manually initiating fsck on /dev/sdb2 has never resulted in an error on either the old disk or the new one. Occasionally, systemd reports an error indicating missing system files (/dev/sda1). Again, manually running fsck against the referenced partition has never resulted in an error. I tried sending this via reportbug, but I've never received an email reply indicating it was received. I was previously running Debian Buster without issue. I upgraded to Debian Bullseye several months ago, but did not experience this problem until sometime after the initial upgrade. If you require additional information, feel free to contact me with your request.
Bug#985279: ITP: python-magicalimport -- Importing a Python module by its physical file path
Package: wnpp
Severity: wishlist
Owner: Adam Cecile
* Package name: python-magicalimport
Version : 0.9.1
Upstream Author : Podhmo
* URL : https://github.com/podhmo/magicalimport
* License : Expat
Programming Lang: Python
Description : Importing a Python module by its physical file path
Python to module to import other modules using there file path.
.
Example: import_from_physical_path("bar.py", here="/tmp/foo", as_="bar")
This module will be maintained withing the Debian Python Module Team.
This package is a dependency of python-prestring which is a dependency of
swagger-marshmallow-codegen (ITP: #985275).
Bug#985231: [Pkg-javascript-devel] Bug#985231: Bug#985231: TypeError: Cannot use 'in' operator to search for 'dependencies' in ../package.json
On 2021, മാർച്ച് 15 4:21:37 PM IST, Nilesh Patra wrote: >> Dear Maintainer, >> >> * What led up to the situation? >> >> I installed node-node-sass, and ran its installed binary node-sass. >> >> * What exactly did you do (or not do) that was effective (or >> ineffective)? >> >> Ran the command "node-sass". I tried running in different paths, with >> different parameters, and on a different system, but the result was >> the same. >> >> * What was the outcome of this action? >> >> $ node-sass >> /usr/share/nodejs/normalize-package-data/lib/fixer.js:138 >> if (!(deps in data)) return >> ^ > >Since node-node-sass is supposed to be used as a library, probably we do not >need to vendor this binary: /usr/bin/node-sass -> >../lib/x86_64-linux-gnu/nodejs/node-sass/bin/node-sass If someone wants to use the binary and someone cares to make it work, we can fix it. If no one steps in to fix this, then we can consider removing it. >Also maybe this bug should be reassigned to node-normalize-package-data? Is node-node-sass using a compatible version of node-normalize-path? May be it is expecting a different API? (If the version node-node-sass expects in its package.json is different from the version available in the archive, this can happen). >@Team, thoughts? > >Nilesh > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#985280: ITP: python-prestring -- Source code generation library (with overuse with-syntax)
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: python-prestring Version : 0.9.0 Upstream Author : Podhmo * URL : https://github.com/podhmo/prestring * License : Expat Programming Lang: Python Description : Source code generation library (with overuse with-syntax) Python to module to generate source code inspired by srcgen. This module will be maintained withing the Debian Python Module Team. This package is a dependency of swagger-marshmallow-codegen (ITP: #985275) and requires python-evilunit package (ITP: #985278).
Bug#984881: libnvidia-ml-dev: missing libnvidia-ml.so in library search path?
Andreas Beckmann, le dim. 14 mars 2021 06:19:28 +0100, a ecrit: > On 11/03/2021 16.57, Samuel Thibault wrote: > > Thanks for the nvidia-alternative upload, but it seems that it then > > doesn't work for ppc64el, which doesn't have the nvidia-alternative > > binary package since it doesn't build the nvidia-graphics-drivers source > > package? > > Now all *-legacy-* and *-tesla-* packages should be updated, too. Thanks! Samuel
