Bug#961552: gnome-contacts: org.gnome.Contacts.png files are not installed

[Simon Désaulniers]

Actually,

I have found the issue: in the desktop file, there is a line

OnlyShowIn=GNOME;Unity;

which prevents awesome (possibly willingly) from loading the entry. I verified
that by overriding the desktop entry, i.e. by moving the desktop file to
~/.local/share/applications and trying with and without the line and without the
line Awesome succeeds in loading the file.

We could think that a patch could solve it in Debian, but I don't think that
this is a good idea since for uniformity's sake patches should be made for all
gnome packages that share this behaviour. This is not reasonable I think. I
guess that the good solution would be for Awesome to override this setting while
loading desktop files or at least let the user enable this behaviour.

Anyways. Case closed. ;)

Regards,

On Tue, May 26, 2020 at 03:47:25PM -0400, Simon Désaulniers wrote:
> Hi,
> 
> > apt-file looks at all the apt sources you have available, so you're seeing
> > the PNG icons in the version in stable. To see what's in the version you
> > actually have installed, use `dpkg -L gnome-contacts`.
> 
> Thanks for clarification! I didn't realize that apt-file was not looking into
> the right branch.
> 
> Yeah. I should have used `dpkg`.
> 
> > It looks as though since 3.31.3, gnome-contacts only installs scalable
> > icons in SVG format. This appears to have been a deliberate upstream
> > change. Is Awesome unable to display those?
> 
> So finally, I think that you're half right: yes it is about Awesome, but it's
> not that it doesn't read SVG, but it's that it's giving up on scanning the 
> whole
> directory since the current code for doing that is not yet efficient enough.
> 
> https://github.com/awesomeWM/awesome/issues/908
> 
> This issue can be closed I think. Thank you for your quick and bright 
> response!
> 
> Regards,
> 
> On Tue, May 26, 2020 at 09:01:32AM +0100, Simon McVittie wrote:
> > Control: retitle -1 gnome-contacts: only has scalable SVG icons, not bitmap 
> > PNG icons
> > 
> > On Mon, 25 May 2020 at 18:24:54 -0400, Simon Désaulniers wrote:
> > > After installing the package, the icon files are not installed on the 
> > > system.
> > > According to apt-file, they should be installed at the following paths:
> > > 
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/22x22/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/32x32/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/48x48/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/512x512/apps/org.gnome.Contacts.png
> > 
> > apt-file looks at all the apt sources you have available, so you're seeing
> > the PNG icons in the version in stable. To see what's in the version you
> > actually have installed, use `dpkg -L gnome-contacts`.
> > 
> > It looks as though since 3.31.3, gnome-contacts only installs scalable
> > icons in SVG format. This appears to have been a deliberate upstream
> > change. Is Awesome unable to display those?
> > 
> > smcv
> 
> -- 
> Simon Désaulniers
> sim.desaulni...@gmail.com



-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#961552: gnome-contacts: org.gnome.Contacts.png files are not installed

[Simon Désaulniers]

Hi,

> apt-file looks at all the apt sources you have available, so you're seeing
> the PNG icons in the version in stable. To see what's in the version you
> actually have installed, use `dpkg -L gnome-contacts`.

Thanks for clarification! I didn't realize that apt-file was not looking into
the right branch.

Yeah. I should have used `dpkg`.

> It looks as though since 3.31.3, gnome-contacts only installs scalable
> icons in SVG format. This appears to have been a deliberate upstream
> change. Is Awesome unable to display those?

So finally, I think that you're half right: yes it is about Awesome, but it's
not that it doesn't read SVG, but it's that it's giving up on scanning the whole
directory since the current code for doing that is not yet efficient enough.

https://github.com/awesomeWM/awesome/issues/908

This issue can be closed I think. Thank you for your quick and bright response!

Regards,

On Tue, May 26, 2020 at 09:01:32AM +0100, Simon McVittie wrote:
> Control: retitle -1 gnome-contacts: only has scalable SVG icons, not bitmap 
> PNG icons
> 
> On Mon, 25 May 2020 at 18:24:54 -0400, Simon Désaulniers wrote:
> > After installing the package, the icon files are not installed on the 
> > system.
> > According to apt-file, they should be installed at the following paths:
> > 
> > gnome-contacts: 
> > /usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/22x22/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/32x32/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/48x48/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/512x512/apps/org.gnome.Contacts.png
> 
> apt-file looks at all the apt sources you have available, so you're seeing
> the PNG icons in the version in stable. To see what's in the version you
> actually have installed, use `dpkg -L gnome-contacts`.
> 
> It looks as though since 3.31.3, gnome-contacts only installs scalable
> icons in SVG format. This appears to have been a deliberate upstream
> change. Is Awesome unable to display those?
> 
> smcv

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#961552: gnome-contacts: org.gnome.Contacts.png files are not installed

[Simon Désaulniers]

Package: gnome-contacts
Version: 3.36.1-1
Severity: normal

Dear Maintainer,

After installing the package, the icon files are not installed on the system.
According to apt-file, they should be installed at the following paths:

gnome-contacts: /usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png
gnome-contacts: /usr/share/icons/hicolor/22x22/apps/org.gnome.Contacts.png
gnome-contacts: /usr/share/icons/hicolor/32x32/apps/org.gnome.Contacts.png
gnome-contacts: /usr/share/icons/hicolor/48x48/apps/org.gnome.Contacts.png
gnome-contacts: /usr/share/icons/hicolor/512x512/apps/org.gnome.Contacts.png

However, the following fails:

file /usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png
/usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png: cannot open 
`/usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png' (No such file or 
directory)

The above results seem to be in contradiction with each other.

This has the effect of "blacklisting" desktop files using this icon on some
systems like the Awesome window manager. I.e. the desktop icons are not used to
populate the list of apps.

Regards,

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-contacts depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcheese-gtk25  3.34.0-1+b2
ii  libcheese8   3.34.0-1+b2
ii  libedataserver-1.2-243.36.2-1
ii  libedataserverui-1.2-2   3.36.2-1
ii  libfolks-eds25   0.14.0-1
ii  libfolks25   0.14.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libgee-0.8-2 0.20.3-1
ii  libglib2.0-0 2.64.2-1
ii  libgnome-desktop-3-193.36.1-2
ii  libgoa-1.0-0b3.36.0-1
ii  libgtk-3-0   3.24.20-1
ii  libhandy-0.0-0   0.0.13-2
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libwayland-server0   1.18.0-1

gnome-contacts recommends no packages.

gnome-contacts suggests no packages.

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#960359: nlohmann-json-dev: cmake configuration files are installed in the wrong directory

[Simon Désaulniers]

Package: nlohmann-json-dev
Version: 2.1.1-1.1
Severity: important
Tags: patch

Dear Maintainer,

When trying to build my project which depends on nlohmann-json-dev 2.1.1, using
CMake leads to configuration files not found. See the error message below:

Could not find a package configuration file provided by "nlohmann_json"
(requested version 2.1.1) with any of the following names:

  nlohmann_jsonConfig.cmake
  nlohmann_json-config.cmake

Add the installation prefix of "nlohmann_json" to CMAKE_PREFIX_PATH or set
"nlohmann_json_DIR" to a directory containing one of the above files.  If
"nlohmann_json" provides a separate development package or SDK, be sure it
has been installed.

This is due to the files not being installed correctly on the system. The
package installs them to the following paths:

/usr/lib/cmake/*.cmake

However, according to CMake documentation~[1], the files should be found under
one of the following directories:

/(lib/|lib*|share)/cmake/*/
/(lib/|lib*|share)/*/
/(lib/|lib*|share)/*/(cmake|CMake)/
/*/(lib/|lib*|share)/cmake/*/
/*/(lib/|lib*|share)/*/
/*/(lib/|lib*|share)/*/(cmake|CMake)/

Therefore, the directory for nlohmann-json should rather be:

/usr/lib/cmake/nlohmann_json/

and not

/usr/lib/cmake/

I did include a patch for fixing this in the attchments of this mail.

Note that the package doesn't seem to build now in unstable due to tests failing
to compile. If you're to provide a new version for this package in order to
address this issue, you may have to disable tests (or go around the issue if you
investigate more than I did). I have attached a patch (for debian/rules file)
for this as well which you can use.

Regards,

[1]: https://cmake.org/cmake/help/v3.13/command/find_package.html

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com
commit cd93409ebc0bac1a0c61a4262801a96673c29995
Author: Simon Désaulniers 
Date:   Mon May 11 18:17:55 2020 -0400

patches: cmake path should contain project name

According to
https://cmake.org/cmake/help/v3.13/command/find_package.html.

diff --git a/debian/patches/0002-fix-path-for-cmake-files.patch b/debian/patches/0002-fix-path-for-cmake-files.patch
index edcf86ba..0bdc9d4a 100644
--- a/debian/patches/0002-fix-path-for-cmake-files.patch
+++ b/debian/patches/0002-fix-path-for-cmake-files.patch
@@ -7,7 +7,7 @@ Subject: fix path for cmake files
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/CMakeLists.txt b/CMakeLists.txt
-index 30e3966..6279544 100644
+index 30e3966..839d2cb 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -13,7 +13,7 @@ set(JSON_PACKAGE_NAME ${JSON_TARGET_NAME})
@@ -15,7 +15,7 @@ index 30e3966..6279544 100644
  set(JSON_CONFIG_FILENAME "${JSON_PACKAGE_NAME}Config.cmake")
  set(JSON_CONFIGVERSION_FILENAME "${JSON_PACKAGE_NAME}ConfigVersion.cmake")
 -set(JSON_CONFIG_DESTINATION "cmake")
-+set(JSON_CONFIG_DESTINATION "lib/cmake")
++set(JSON_CONFIG_DESTINATION "lib/cmake/${PROJECT_NAME}/")
  set(JSON_INCLUDE_DESTINATION "include/nlohmann")
  
  set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
diff --git a/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch b/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch
index 4db82c9e..ecd746fe 100644
--- a/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch
+++ b/debian/patches/bea1665ac9a5e7aa4fa93668ff35723385a27bfd.patch
@@ -7,11 +7,11 @@ Subject: [PATCH] modify json.hpp to compile with recent gcc
 
 https://github.com/nlohmann/json/issues/606
 ---
- src/json.hpp | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
+ src/json.hpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/json.hpp b/src/json.hpp
-index c2e1f20..48d797d 100644
+index 6dfc183..5259d06 100644
 --- a/src/json.hpp
 +++ b/src/json.hpp
 @@ -6054,7 +6054,7 @@ class basic_json
commit 5df7a99f4fff4e564da65ad884926dd6aff402b6
Author: Simon Désaulniers 
Date:   Mon May 11 19:39:35 2020 -0400

rules: don't build tests

diff --git a/debian/rules b/debian/rules
index 9ab5610f..8701eb09 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,9 @@ override_dh_clean:
 	dh_clean
 	make -C doc clean
 
+override_dh_auto_configure:
+	dh_auto_configure -- -DBuildTests=OFF
+
 override_dh_auto_build:
 	make re2c
 	make -C doc


signature.asc
Description: PGP signature

Bug#959495: ITP: dpaste -- Pastebin using OpenDHT distributed hash table

[Simon Désaulniers]

Package: wnpp
Severity: wishlist
Owner: Simon Désaulniers 

* Package name: dpaste
  Version : 0.3.3
  Upstream Author : Simon Désaulniers 
* URL : https://github.com/sim590/dpaste
* License : GPL
  Programming Lang: C++
  Description : Pastebin using OpenDHT distributed hash table

A distributed pastebin which requires no central server to paste your files (up
to a size of 64KiB).

This package would be useful for exchanging small files to be shared
momentarily, for e.g. on IRC or other sorts of group discussion platforms. The
program works using a distributed hash table, therefore it doesn't suffer from
limitations of centralized software like inaccessibility or censorship. The
usage of this program is also lightweight and therefore removes the need for a
central server to carry the burden of maintaining a service which is completely
achievable through light peer-to-peer software.

I have already created a package for this and I will close this bug soon.

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#958504: Update: changelog with "Closes" referencing this bug

[Simon Désaulniers]

Hi,

I did update my contribution to include the "Closes" word referencing this bug:

https://salsa.debian.org/sim590-guest/libappindicator1/-/commit/b7cfa628cd88e83ed08279bfa33e3443ace15e19

In summary, the complete list of changes to "pull" have the following
identifiers (commit hashes):

c52b957f1937f30ee8af72447709644d42727ce5
b7cfa628cd88e83ed08279bfa33e3443ace15e19

from repository https://salsa.debian.org/sim590-guest/libappindicator1.

Regards,

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#958504: libappindicator1:amd64: segfault for multiple apps like Discord

[Simon Désaulniers]

Package: libappindicator1
Version: 0.4.92-7
Severity: important
Tags: patch upstream

Dear person who will take the responsability (package is not maintained),

There is a nasty bug in this library that creates crashses in some popular
applications such as Discord. The bug is documented here:

https://bugs.launchpad.net/ubuntu/+source/libappindicator/+bug/1867996

and the following page indicates that it has been fixed through patching by the
Ubuntu package contributors.

https://launchpad.net/ubuntu/+source/libappindicator/12.10.1+20.04.20200408.1-0ubuntu1

I have taken the liberty to include this fix in this Debian package. One can
find my fix here:

https://salsa.debian.org/sim590-guest/libappindicator1/-/commit/c52b957f1937f30ee8af72447709644d42727ce5

I have included a patch and have also updated the changelog appropriately.
Although, I will need to include a "#Closes" clause as soon as this bug is
created through the sending of this mail.

Please take the time to upload my change for a new version of this package
quickly.

Regards,


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-rc5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libappindicator1:amd64 depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libdbusmenu-glib418.10.20180917~bzr492+repack1-2
ii  libdbusmenu-gtk4 18.10.20180917~bzr492+repack1-2
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.1-1
ii  libgtk2.0-0  2.24.32-4
ii  libindicator70.5.0-4
ii  libpango-1.0-0   1.44.7-3
ii  libpangocairo-1.0-0  1.44.7-3
ii  libpangoft2-1.0-01.44.7-3

libappindicator1:amd64 recommends no packages.

libappindicator1:amd64 suggests no packages.

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update

[Simon Désaulniers]

Hi,

I have gone back working on this issue and I can confirm that the issue is due
to the socket. It seems like this "socket" unit is disabling usage of a Unix
socket in favor of a TCP socket. What do you recommend for someone who wants to
use a UNIX socket? Should I edit the socket file in some way or simply disable
it?

Regards,

On Sat, Jan 04, 2020 at 04:17:24PM -0500, Simon Désaulniers wrote:
> Dear contributors,
> 
> To this day, I can't reproduce what I was talking about in my initial post.
> Therefore, I assume that the issue resolved somehow. I can't say what changed
> between those now and then and I think that we can close this issue.
> 
> Regards,
> 
> On Thu, Nov 07, 2019 at 11:34:03AM +0100, Florian Schlichting wrote:
> > Hi Simon,
> > 
> > On Tue, Oct 01, 2019 at 04:14:40PM +0200, kaliko wrote:
> > > On Sun, 28 Jul 2019 17:14:08 -0400 Simon Désaulniers 
> > >  wrote:
> > > > […] 
> > > > After upgrading from 0.21.5-3 to 0.21.11-1, systemd's mpd service 
> > > > doesn't seem
> > > > to use the UNIX socket configured from my mpd configuration located at
> > > > /home/simon/.config/mpd/mpd.conf.
> > > > […]
> > > 
> > > I did not manage to reproduce the issue.
> > > I'll try again later on a freshly installed VM upgraded to testing, but 
> > > so far I have
> > > not been able to reproduce the issue (tested also with mpd 0.21.15).
> > > 
> > > Maybe someone from MPD team is willing to give it a shot.
> > 
> > with version 0.21.8, mpd gained a _user_ mpd.socket unit, which defines
> > 
> > ListenStream=%t/mpd/socket
> > ListenStream=6600
> > 
> > and is enabled by default. My feeling is that this is responsible for
> > your observed differences between using systemctl and manually launching
> > mpd. Did mpd.socket get stopped/restarted in your testing?
> > 
> > HTH,
> > Florian
> > 
> 
> -- 
> Simon Désaulniers
> sim.desaulni...@gmail.com



-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#934444: i3lock-fancy does not fork

[Simon Désaulniers]

Hi dirdi,

I took your advice into accoutn and included the full notice under KNOWN BUGS
section while keeping a short (but highlighted) notice under the option's
description. This way, there should be no confusion. Thank you for the advice.

Regards,

On Wed, Jan 15, 2020 at 08:15:28PM +0100, dirdi wrote:
> @Simon: I think a notice should be sufficient, until the bug is fixed.
> However, I would add a "KNOWN BUGS" section to the end of the man page
> (cf. atool's man page:
> https://manpages.debian.org/buster/atool/atool.1.en.html) and file the
> notice under this section.

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#934444: i3lock-fancy does not fork

[Simon Désaulniers]

I have produced this patch (attached to this mail). If you think that this is
not sufficient, tell me. The patch won't be merged until a couple of days
anyway.

On Fri, Jan 10, 2020 at 04:18:40PM -0500, Simon Désaulniers wrote:
> Hi again,
> 
> Actually, I have just looked at the man page and the faulty behaviour is not
> about the option `-n`, but the default program behaviour as you said 
> previously.
> However, this is under documentation for `-n` that forking is mentioned.
> Therefore, the second suggestion about removing the option just doesn't make
> sense as a temporary fix for this issue. Consequently, a notice is best I 
> think.
> 
> Regards,
> 
> On Fri, Jan 10, 2020 at 04:07:22PM -0500, Simon Désaulniers wrote:
> > Hi dirdi,
> > 
> > You are right. Would you simply add a notice in the man page by forwarding 
> > to
> > the upstream bug URL? Or would you totally remove the option from the man 
> > page?
> > I am more tempted in doing the former. What do you think?
> > 
> > Regards,
> > 
> > On Mon, Jan 06, 2020 at 04:29:09AM +0100, dirdi wrote:
> > > Package: i3lock-fancy
> > > Version: 0.0~git20160228.0.0fcb933-2
> > > Followup-For: Bug #93
> > > 
> > > I suggest to at least patch the man page and document the actual 
> > > behavior, since not forking might have severe security implications: E.g. 
> > > consider the following shell script which is supposed to lock the screen 
> > > and wipe all identities from the SSH agent:
> > > 
> > > > #! /bin/sh
> > > > i3lock-fancy
> > > > ssh-add -d
> > > 
> > > Instead of wiping those identities instantly they will not be wiped
> > > before i3lock-fancy exits (i.e. screen being unlocked).
> > 
> > -- 
> > Simon Désaulniers
> > sim.desaulni...@gmail.com
> 
> 
> 
> -- 
> Simon Désaulniers
> sim.desaulni...@gmail.com



-- 
Simon Désaulniers
sim.desaulni...@gmail.com
diff --git a/debian/i3lock-fancy.1 b/debian/i3lock-fancy.1
index ba8b2c6..b0514c3 100644
--- a/debian/i3lock-fancy.1
+++ b/debian/i3lock-fancy.1
@@ -50,7 +50,11 @@ immediately.
 
 .TP
 \fB-n, --nofork\fP
-Do not fork i3lock after starting.
+Do not fork i3lock after starting. 
+
+\fIIMPORTANT\fP: As of now, forking \fBdoes not\fP occur whether one uses `-n` or not. See
+https://github.com/meskarune/i3lock-fancy/issues/144 for more information
+regarding this bug.
 
 .TP
 \fB--\fP


signature.asc
Description: PGP signature

Bug#934444: i3lock-fancy does not fork

[Simon Désaulniers]

Hi again,

Actually, I have just looked at the man page and the faulty behaviour is not
about the option `-n`, but the default program behaviour as you said previously.
However, this is under documentation for `-n` that forking is mentioned.
Therefore, the second suggestion about removing the option just doesn't make
sense as a temporary fix for this issue. Consequently, a notice is best I think.

Regards,

On Fri, Jan 10, 2020 at 04:07:22PM -0500, Simon Désaulniers wrote:
> Hi dirdi,
> 
> You are right. Would you simply add a notice in the man page by forwarding to
> the upstream bug URL? Or would you totally remove the option from the man 
> page?
> I am more tempted in doing the former. What do you think?
> 
> Regards,
> 
> On Mon, Jan 06, 2020 at 04:29:09AM +0100, dirdi wrote:
> > Package: i3lock-fancy
> > Version: 0.0~git20160228.0.0fcb933-2
> > Followup-For: Bug #93
> > 
> > I suggest to at least patch the man page and document the actual behavior, 
> > since not forking might have severe security implications: E.g. consider 
> > the following shell script which is supposed to lock the screen and wipe 
> > all identities from the SSH agent:
> > 
> > > #! /bin/sh
> > > i3lock-fancy
> > > ssh-add -d
> > 
> > Instead of wiping those identities instantly they will not be wiped
> > before i3lock-fancy exits (i.e. screen being unlocked).
> 
> -- 
> Simon Désaulniers
> sim.desaulni...@gmail.com



-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#934444: i3lock-fancy does not fork

[Simon Désaulniers]

Hi dirdi,

You are right. Would you simply add a notice in the man page by forwarding to
the upstream bug URL? Or would you totally remove the option from the man page?
I am more tempted in doing the former. What do you think?

Regards,

On Mon, Jan 06, 2020 at 04:29:09AM +0100, dirdi wrote:
> Package: i3lock-fancy
> Version: 0.0~git20160228.0.0fcb933-2
> Followup-For: Bug #93
> 
> I suggest to at least patch the man page and document the actual behavior, 
> since not forking might have severe security implications: E.g. consider the 
> following shell script which is supposed to lock the screen and wipe all 
> identities from the SSH agent:
> 
> > #! /bin/sh
> > i3lock-fancy
> > ssh-add -d
> 
> Instead of wiping those identities instantly they will not be wiped
> before i3lock-fancy exits (i.e. screen being unlocked).

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#934444: i3lock-fancy does not fork

[Simon Désaulniers]

Hi again,

I have been told that we don't close upstream bugs. In fact, you clearly tagged
it accordingly. Therefore, I guess you should forget my comment. I will reopen
this bug and flag it as forwarded to the upstream issue I mentioned before.
We'll wait for reoslution from upstream.

Regards,

On Sun, Jan 05, 2020 at 04:17:58PM -0500, Simon Désaulniers wrote:
> Hi,
> 
> > Unlike the man page suggests, i3lock-fancy does not fork, no matter if the 
> > -n argument was supplied or not.
> 
> This issue is not related to any manipulation on the packager's end. This is 
> an
> upstream issue. In fact, a bug report has been filed [1] in upstream's bug
> tracking system exactly 6 months before your bug report here. There is 
> nothing I
> can do really. You can try to make some noise in upstream's BTS.
> 
> Keep in mind that the Debian package is also based on dualmonitor branch of
> upstream's project. If there was a fix over there, it would have to be ported 
> to
> the dualmonitor branch also for us to use this fix.
> 
> Since there's nothing to do really here, I will close this bug report.
> 
> Regards,
> 
> [1]: https://github.com/meskarune/i3lock-fancy/issues/144
> 
> Le sam. 10 août 2019, à 21 h 51, dirdi  a écrit :
> 
> > Package: i3lock-fancy
> > Version: 0.0~git20160228.0.0fcb933-2
> > Severity: normal
> > Tags: upstream
> >
> > Unlike the man page suggests, i3lock-fancy does not fork, no matter if the 
> > -n argument was supplied or not.
> >
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers testing
> >   APT policy: (500, 'testing'), (50, 'unstable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_US:en (charmap=UTF-8)
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages i3lock-fancy depends on:
> > ii  gawk 1:4.2.1+dfsg-1.1
> > ii  i3lock   2.11.1-1
> > ii  imagemagick  8:6.9.10.23+dfsg-2.1
> > ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
> > ii  mawk 1.3.3-17+b3
> > ii  scrot1.1.1-1
> >
> > i3lock-fancy recommends no packages.
> >
> > Versions of packages i3lock-fancy suggests:
> > pn  maim
> > pn  wmctrl  
> >
> > -- no debconf information
> >

>s
>Le sam. 10 août 2019, à 21 h 51, dirdi <[1]deb...@dirdi.name> a écrit :
> 
>  Package: i3lock-fancy
>  Version: 0.0~git20160228.0.0fcb933-2
>  Severity: normal
>  Tags: upstream
> 
>  Unlike the man page suggests, i3lock-fancy does not fork, no matter if
>  the -n argument was supplied or not.
> 
>  -- System Information:
>  Debian Release: bullseye/sid
>    APT prefers testing
>    APT policy: (500, 'testing'), (50, 'unstable')
>  Architecture: amd64 (x86_64)
> 
>  Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
>  Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>  Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>  LANGUAGE=en_US:en (charmap=UTF-8)
>  Shell: /bin/sh linked to /usr/bin/dash
>  Init: systemd (via /run/systemd/system)
>  LSM: AppArmor: enabled
> 
>  Versions of packages i3lock-fancy depends on:
>  ii  gawk                             1:4.2.1+dfsg-1.1
>  ii  i3lock                           2.11.1-1
>  ii  imagemagick                      8:6.9.10.23+dfsg-2.1
>  ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
>  ii  mawk                             1.3.3-17+b3
>  ii  scrot                            1.1.1-1
> 
>  i3lock-fancy recommends no packages.
> 
>  Versions of packages i3lock-fancy suggests:
>  pn  maim    
>  pn  wmctrl  
> 
>  -- no debconf information
> 
> References
> 
>Visible links
>1. mailto:deb...@dirdi.name




-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#934444: i3lock-fancy does not fork

[Simon Désaulniers]

Hi,

> Unlike the man page suggests, i3lock-fancy does not fork, no matter if the 
> -n argument was supplied or not.

This issue is not related to any manipulation on the packager's end. This is an
upstream issue. In fact, a bug report has been filed [1] in upstream's bug
tracking system exactly 6 months before your bug report here. There is nothing I
can do really. You can try to make some noise in upstream's BTS.

Keep in mind that the Debian package is also based on dualmonitor branch of
upstream's project. If there was a fix over there, it would have to be ported to
the dualmonitor branch also for us to use this fix.

Since there's nothing to do really here, I will close this bug report.

Regards,

[1]: https://github.com/meskarune/i3lock-fancy/issues/144

Le sam. 10 août 2019, à 21 h 51, dirdi  a écrit :

> Package: i3lock-fancy
> Version: 0.0~git20160228.0.0fcb933-2
> Severity: normal
> Tags: upstream
>
> Unlike the man page suggests, i3lock-fancy does not fork, no matter if the 
> -n argument was supplied or not.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (50, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3lock-fancy depends on:
> ii  gawk 1:4.2.1+dfsg-1.1
> ii  i3lock   2.11.1-1
> ii  imagemagick  8:6.9.10.23+dfsg-2.1
> ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
> ii  mawk 1.3.3-17+b3
> ii  scrot1.1.1-1
>
> i3lock-fancy recommends no packages.
>
> Versions of packages i3lock-fancy suggests:
> pn  maim
> pn  wmctrl  
>
> -- no debconf information
>
sLe sam. 10 août 2019, à 21 h 51, dirdi  a écrit :Package: i3lock-fancy
Version: 0.0~git20160228.0.0fcb933-2
Severity: normal
Tags: upstream

Unlike the man page suggests, i3lock-fancy does not fork, no matter if the -n argument was supplied or not.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages i3lock-fancy depends on:
ii  gawk                             1:4.2.1+dfsg-1.1
ii  i3lock                           2.11.1-1
ii  imagemagick                      8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  mawk                             1.3.3-17+b3
ii  scrot                            1.1.1-1

i3lock-fancy recommends no packages.

Versions of packages i3lock-fancy suggests:
pn  maim    
pn  wmctrl  

-- no debconf information



signature.asc
Description: PGP signature

Bug#908094: i3lock-fancy: new upstream version

[Simon Désaulniers]

Hi Brian,

Sorry for the small response delay. ;) This is my only Debian package and I have
let things go for a while now. I'm trying to get back on this.

> Maybe. However it is probably not a bug in xss-lock... How would you
> phrase such a question?

I'm not sure. :D

According to the upstream's README file, they're supposed to "pick" the changes
from master to the `dualmonitor` branch (see [1]), so I think that you should
try to propose the change there at least, i.e. make a pull request onto the
`dualbranch` over the upsteam repository.

However, since this change is really deal breaker for you (and some others using
xss-lock) and since upstream doesn't do much to advance development of the
`dualmonitor` branch, then I think that we should include your patch in the
meantime. I have tested it and it works nicely for me. The only thing bothering
me is that it takes one additional second to spawn the script (I tested with
`time` multiple times on both versions). Anyway, that's not too bad, I guess.

I'll upload the change shortly and close this issue.

[1]: https://github.com/meskarune/i3lock-fancy#multiple-monitors

Le lun. 10 sept. 2018, à 18 h 12, Brian May  a écrit :

> Simon Désaulniers  writes:
>
> > Noted. May be that would be worth to formulate as a question to 
> xss-lock's
> > upstream too?
>
> Maybe. However it is probably not a bug in xss-lock... How would you
> phrase such a question?
> -- 
> Brian May 
>
Le lun. 10 sept. 2018, à 18 h 12, Brian May <b...@debian.org> a écrit :Simon Désaulniers <sim.desaulni...@gmail.com> writes:

> Noted. May be that would be worth to formulate as a question to xss-lock's
> upstream too?

Maybe. However it is probably not a bug in xss-lock... How would you
phrase such a question?
-- 
Brian May <b...@debian.org>



signature.asc
Description: PGP signature

Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update

[Simon Désaulniers]

Dear contributors,

To this day, I can't reproduce what I was talking about in my initial post.
Therefore, I assume that the issue resolved somehow. I can't say what changed
between those now and then and I think that we can close this issue.

Regards,

On Thu, Nov 07, 2019 at 11:34:03AM +0100, Florian Schlichting wrote:
> Hi Simon,
> 
> On Tue, Oct 01, 2019 at 04:14:40PM +0200, kaliko wrote:
> > On Sun, 28 Jul 2019 17:14:08 -0400 Simon Désaulniers 
> >  wrote:
> > > […] 
> > > After upgrading from 0.21.5-3 to 0.21.11-1, systemd's mpd service doesn't 
> > > seem
> > > to use the UNIX socket configured from my mpd configuration located at
> > > /home/simon/.config/mpd/mpd.conf.
> > > […]
> > 
> > I did not manage to reproduce the issue.
> > I'll try again later on a freshly installed VM upgraded to testing, but so 
> > far I have
> > not been able to reproduce the issue (tested also with mpd 0.21.15).
> > 
> > Maybe someone from MPD team is willing to give it a shot.
> 
> with version 0.21.8, mpd gained a _user_ mpd.socket unit, which defines
> 
> ListenStream=%t/mpd/socket
> ListenStream=6600
> 
> and is enabled by default. My feeling is that this is responsible for
> your observed differences between using systemctl and manually launching
> mpd. Did mpd.socket get stopped/restarted in your testing?
> 
> HTH,
> Florian
> 

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update

[Simon Désaulniers]

Package: mpd
Version: 0.21.11-1
Severity: normal

Dear Maintainer,

After upgrading from 0.21.5-3 to 0.21.11-1, systemd's mpd service doesn't seem
to use the UNIX socket configured from my mpd configuration located at
/home/simon/.config/mpd/mpd.conf. I safely assume this due to the fact that
calling `mpd --no-daemon` myself (the same command found in `ExecStart=` line)
lead to mpd using the UNIX socket `~/.mpd/socket` that I configured which is not
the case for the systemd service. More precisely:

* Using systemd service:
  1) systemctl --user mask --now mpd
  2) rm -f ~/.mpd/socket
  3) systemctl --user unmask mpd; systemctl --user start mpd
  4) ls ~/.mpd # and notice the file is not there
* Using manual luanch:
  1) systemctl --user mask --now mpd
  2) rm -f ~/.mpd/socket
  3) mpd --no-daemon
  4) ls ~/.mpd # and notice the file is there

Therefore, the following configuration line from my personal file is read in the
second case, but not in the first:

  bind_to_address   "/home/simon/.mpd/socket"

I'm not really sure what's causing this.

Regards,

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=eo 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.57
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-1
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.3-1
ii  libavformat58 7:4.1.3-1
ii  libavutil56   7:4.1.3-1
ii  libbz2-1.01.0.6-9.2
ii  libc6 2.28-10
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libcurl3-gnutls   7.65.1-1
ii  libdbus-1-3   1.12.16-1
ii  libexpat1 2.2.7-1
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.2-3
ii  libfluidsynth11.1.11-1+b1
ii  libgcc1   1:9.1.0-10
ii  libgcrypt20   1.8.4-5
ii  libgme0   0.6.2-1
ii  libicu63  63.2-2
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.0.0-2
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjs-sphinxdoc   1.8.5-2
ii  libmad0   0.15.1b-10
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   3.100-2+b1
ii  libmpcdec62:0.1~r495-1+b2
ii  libmpdclient2 2.16-1
ii  libmpg123-0   1.25.10-2
ii  libnfs12  3.0.0-2
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-1
ii  libopus0  1.3-1
ii  libpcre3  2:8.39-12
ii  libpulse0 12.2-4
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1
ii  libsmbclient  2:4.9.11+dfsg-1
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.29.0-1
ii  libstdc++69.1.0-10
ii  libsystemd0   241-7
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libwavpack1   5.1.0-7
ii  libwildmidi2  0.4.3-1
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.62-3.2
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon  0.7-4+b1
pn  icecast2  
ii  mpc [mpd-client]  0.31-1
ii  ncmpcpp [mpd-client]  0.8.2-0.1+b1
ii  pulseaudio12.2-4

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


sig

Bug#927090: [ilwmvm] Recurent kernel panic crash at iwl_mvm_async_handlers_wk+0xba/0x160

[Simon Désaulniers]

Hi,

Something went wrong with `reportbug`. Here is the complete journal log attached
to this mail.

Regards,

-- 
Simon Désaulniers
sim.desaulni...@gmail.com
-- Logs begin at Fri 2019-02-08 12:50:34 EST, end at Sun 2019-04-14 19:59:22 
EDT. --
avr 12 22:18:32 haxorz kernel: thinkpad_acpi: battery 1 registered (start 0, 
stop 100)
avr 12 22:18:32 haxorz kernel: battery: new extension: ThinkPad Battery 
Extension
avr 12 22:18:32 haxorz kernel: input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input8
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: checking generic (e000 7f) vs hw 
(e000 1000)
avr 12 22:18:32 haxorz kernel: fb: switching to inteldrmfb from EFI VGA
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: Console: switching to colour dummy device 80x25
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed: -22
avr 12 22:18:32 haxorz kernel: pstore: crypto_comp_decompress failed, ret = -22!
avr 12 22:18:32 haxorz kernel: pstore: decompression failed

Bug#927090: [ilwmvm] Recurent kernel panic crash at iwl_mvm_async_handlers_wk+0xba/0x160

[Simon Désaulniers]

Package: src:linux
Version: 4.19.28-2
Severity: important
File: 
/lib/modules/4.19.0-4-amd64/kernel/drivers/net/wireless/intel/iwlwifi/mvm/iwlmvm.ko

Dear Maintainer,

I have been having recurrent kernel panic crashes with iwlmvm module. I can't
say how it happens. It seems random from my standpoint of view. Here is the
complete kernel crash backtrace:

avr 14 17:23:24 haxorz kernel: mmc0: cannot verify signal voltage switch
avr 14 17:23:24 haxorz kernel: e1000e: enp0s31f6 NIC Link is Down
avr 14 17:23:25 haxorz kernel: WARNING: CPU: 0 PID: 28576 at 
drivers/net/wireless/intel/iwlwifi/mvm/scan.c:1786 
iwl_mvm_rx_umac_scan_complete_notif+0x158/0x170 [iwlmvm]
avr 14 17:23:25 haxorz kernel: Modules linked in: ses enclosure 
scsi_transport_sas uas usb_storage hid_generic usbhid hid snd_usb_audio 
snd_usbmidi_lib snd_rawmidi snd_seq_device ipt_MASQUERADE nf_conntrack_netli
avr 14 17:23:25 haxorz kernel:  coretemp kvm_intel snd_soc_skl 
snd_soc_skl_ipc iwlmvm snd_soc_sst_ipc kvm snd_soc_sst_dsp irqbypass mac80211 
snd_hda_ext_core intel_cstate snd_soc_acpi_intel_match snd_soc_acpi int
avr 14 17:23:25 haxorz kernel:  crc32c_intel ghash_clmulni_intel pcbc 
rtsx_pci_sdmmc mmc_core aesni_intel ahci xhci_pci aes_x86_64 crypto_simd 
libahci cryptd glue_helper xhci_hcd libata psmouse e1000e usbcore scs
avr 14 17:23:25 haxorz kernel: CPU: 0 PID: 28576 Comm: kworker/0:1 Tainted: 
GW  OE 4.19.0-4-amd64 #1 Debian 4.19.28-2
avr 14 17:23:25 haxorz kernel: Hardware name: LENOVO 20F9003CCA/20F9003CCA, 
BIOS N1CET74W (1.42 ) 02/07/2019
avr 14 17:23:25 haxorz kernel: Workqueue: events iwl_mvm_async_handlers_wk 
[iwlmvm]
avr 14 17:23:25 haxorz kernel: RIP: 
0010:iwl_mvm_rx_umac_scan_complete_notif+0x158/0x170 [iwlmvm]
avr 14 17:23:25 haxorz kernel: Code: 39 ff ff ff 48 8b 7f 28 e8 b5 76 04 00 
8b 95 98 18 00 00 c7 85 b8 18 00 00 00 00 00 00 41 8b 84 24 1c 19 00 00 e9 13 
ff ff ff <0f> 0b e9 35 ff ff ff e8 ac c3 cd ce 66 66 2e 0f
avr 14 17:23:25 haxorz kernel: RSP: 0018:a55f49c8fe10 EFLAGS: 00010246
avr 14 17:23:25 haxorz kernel: RAX: 0100 RBX: 9a0d12079000 
RCX: c0f9eb80
avr 14 17:23:25 haxorz kernel: RDX:  RSI: 9a0cbbef1c50 
RDI: 9a0d1a999548
avr 14 17:23:25 haxorz kernel: RBP: a55f49c8fe50 R08: 9a0d1d222620 
R09: 
avr 14 17:23:25 haxorz kernel: R10:  R11: 9a0d1d220be8 
R12: 9a0d1a999548
avr 14 17:23:25 haxorz kernel: R13: 9a0cbbef1c40 R14: dead0100 
R15: 9a0cbbef1c40
avr 14 17:23:25 haxorz kernel: FS:  () 
GS:9a0d1d20() knlGS:
avr 14 17:23:25 haxorz kernel: CS:  0010 DS:  ES:  CR0: 
80050033
avr 14 17:23:25 haxorz kernel: CR2: 7f88cc10 CR3: 7b40a002 
CR4: 003606f0
avr 14 17:23:25 haxorz kernel: Call Trace:
avr 14 17:23:25 haxorz kernel:  iwl_mvm_async_handlers_wk+0xba/0x160 
[iwlmvm]
avr 14 17:23:25 haxorz kernel:  process_one_work+0x1a7/0x3a0
avr 14 17:23:25 haxorz kernel:  worker_thread+0x30/0x390
avr 14 17:23:25 haxorz kernel:  ? create_worker+0x1a0/0x1a0
avr 14 17:23:25 haxorz kernel:  kthread+0x112/0x130
avr 14 17:23:25 haxorz kernel:  ? kthread_bind+0x30/0x30
avr 14 17:23:25 haxorz kernel:  ret_from_fork+0x35/0x40
avr 14 17:23:25 haxorz kernel: ---[ end trace 457db209ade39170 ]---

You can read the whole journal log file in the attached files section.

I know. That hostname though. Anyway. ;)

Regards,

-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 root=/dev/mapper/haxorz--vg-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   12.144820] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
[   12.148357] Bluetooth: hci0: Applying Intel DDC parameters completed
[   12.164687] Console: switching to colour frame buffer device 240x67
[   12.199141] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   12.228416] new mount options do not match the existing superblock, will be 
ignored
[   12.248829] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC293: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   12.248832] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.248834] snd_hda_codec_realtek hdaudioC0D0:hp_outs=2 
(0x16/0x15/0x0/0x0/0x0)
[   12.248835] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   12.248837] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   12.248838] snd_hda_codec_realtek hdaudioC0D0:  Dock Mic=0x19
[   12.248840] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x1a
[   12.248842] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[   12.337131] 

Bug#908094: i3lock-fancy: new upstream version

[Simon Désaulniers]

Hi,

On Thu, Sep 06, 2018 at 04:37:21PM +1000, Brian May wrote:
> Simon Désaulniers  writes:
> 
> > Unless there are important issues concerning this request, I don't
> > think that we should do that for reasons I mentionned above. Please,
> > feel free to respond if I'm missing something important.
> 
> :-(
> 
> Would you consider this patch? Seems that upstream use "import" not
> instead of "scrot" (despite documentation saying otherwise).

I will look into it soon.

> For reasons I don't fully comprehend, scrot when called from xss-lock
> always produces a black bitmap, but after this change it works fine.

Noted. May be that would be worth to formulate as a question to xss-lock's
upstream too?

> 
> --- /usr/bin/i3lock-fancy 2018-01-26 15:54:36.0 +1100
> +++ bin/lock.sh   2018-09-06 16:29:53.025279474 +1000
> @@ -49,7 +49,7 @@
>  pl_* ) TEXT="Podaj hasło" ;; # Polish
>  esac
>  
> -scrot -z "$IMAGE"
> +import -window root "$IMAGE"
>  ICON="$SCRIPTPATH/lock.png"
>  PARAM=(--textcolor=ff00 --insidecolor=ff1c --ringcolor=ff3e \
> --linecolor=ff00 --keyhlcolor=0080 --ringvercolor= \
> 
> -- 
> Brian May 

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#908094: i3lock-fancy: new upstream version

[Simon Désaulniers]

Hi Brian,

When I first thought about packaging i3lock-fancy, I didn't consider the program
packagable if it would not handle multiple monitors appropriately. At the time,
there was (and there still is) the "dualmonitors" branch which was giving good
results (and still does) so I decided to package it while hoping the branch
would eventually be merged.

> Actually I am somewhat confused, the Debian package seems to contain
> functionality to support multiple monitors not in upstream. Maybe this
> could be pushed upstream first?

Sadly, as you can see from upstream repository, there were multiple
attempts~[1,2,3] at merging the functionnality, but it never did.

> Version in Debian unstable is very old, please consider updating to at
> least version 0.2, the latest release.

Unless there are important issues concerning this request, I don't think that we
should do that for reasons I mentionned above. Please, feel free to respond if
I'm missing something important.

Regards,

[1]: https://github.com/meskarune/i3lock-fancy/pull/68
[2]: https://github.com/meskarune/i3lock-fancy/pull/84
[3]: https://github.com/meskarune/i3lock-fancy/pull/87

On Thu, Sep 06, 2018 at 03:41:14PM +1000, Brian May wrote:
> Package: i3lock-fancy
> Version: 0.0~git20160228.0.0fcb933-2
> Severity: wishlist
> 
> 
> Version in Debian unstable is very old, please consider updating to at
> least version 0.2, the latest release.
> 
> Actually I am somewhat confused, the Debian package seems to contain
> functionality to support multiple monitors not in upstream. Maybe this
> could be pushed upstream first?
> 
> Thanks
> 
> -- System Information:
> Debian Release: 9.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.16.0-0.bpo.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.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages i3lock-fancy depends on:
> ii  gawk 1:4.1.4+dfsg-1
> ii  i3lock   2.8-1
> ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u5
> ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u5
> ii  mawk 1.3.3-17+b3
> ii  scrot0.8-18
> 
> i3lock-fancy recommends no packages.
> 
> Versions of packages i3lock-fancy suggests:
> ii  maim3.3.41-1+b1
> pn  wmctrl  
> 
> -- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#868112: nlohmann-json-dev: include dir: wrong

[Simon Désaulniers]

Package: nlohmann-json-dev
Version: 2.0.6-1
Severity: important

Dear Maintainer,

As [1] shows, upstream has default installation path as
`$libdir/nlohmann/json.hpp`, but debian package installs the lib under $libdir.
Archlinux AUR package honors this. I think the right thing should be to use what
upstream decides as installation location, no?

Regards,

[1]: https://github.com/nlohmann/json/blob/develop/CMakeLists.txt#L17


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (750, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#868108: pkg-config: version field is empty

[Simon Désaulniers]

Bug has been noticed to upstream:

https://github.com/jpbarrette/curlpp/issues/47

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#868108: pkg-config: version field is empty

[Simon Désaulniers]

In my last message, reference [2] should be reference [1].

Also, I wanted to mention I have a debian package (dpaste) awaiting upload which
depends on libcurlpp 0.8.1.

Regards,

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#868108: pkg-config: version field is empty

[Simon Désaulniers]

Package: libcurlpp-dev
Version: 0.8.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

Packages depending on a specific version get an error when requiring package
version *using autotools*. For e.g., this:

PKG_CHECK_MODULES([CURLPP], [curlpp >= 0.8.1])

Using CMake seems to work okay though. Version number in resulting pkg-config
file is empty. Indeed, I have checked upstream and it appears that it's their
fault. Their output file from calling `cmake` doesn't produce a version number
in the curlpp.pc file. I think that's the explanation. This bug will be reported
upstream.

While waiting for upstream fix, could you upload a new version with the
appropriate version number by applying a patch to curlpp.pc? I think that should
fix the problem.

Also, it may be possible upstream doesn't support autotools regarding this~[1].
In any case, I think the debian package should make sure packages using
autotools can require a version of this lib in an appropriate manner. What do
you think?

Regards,

[1]: https://anonscm.debian.org/cgit/collab-maint/dpaste.git/
[2]: https://github.com/jpbarrette/curlpp/issues/34#issuecomment-276893343


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (750, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcurlpp-dev depends on:
ii  libcurlpp0  0.8.1-1

libcurlpp-dev recommends no packages.

libcurlpp-dev suggests no packages.

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#866586: [cmake] install cmake find_package files

[Simon Désaulniers]

Package: libopendht-dev
Version: 1.3.3-1
Severity: important

Hi,

When running CMake in OpenDHT, the program will generate some files which are
needed to find OpenDHT if one uses CMake as build system. The files are as
follows:

${CMAKE_RUNDIR}/CMakeFiles/Export/lib/cmake/opendht/opendhtConfig-release.cmake
${CMAKE_RUNDIR}/CMakeFiles/Export/lib/cmake/opendht/opendhtConfig.cmake
${CMAKE_RUNDIR}/opendhtConfigVersion.cmake

Those files need to be installed as:

/usr/local/lib/cmake/opendht/opendhtConfig.cmake
/usr/local/lib/cmake/opendht/opendhtConfig-release.cmake
/usr/local/lib/cmake/opendht/opendhtConfigVersion.cmake

Regards,

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#866359: ITP: dpaste - pastebin based on a DHT

[Simon Désaulniers]

Subject: ITP: dpaste -- pastebin over a DHT
Package: wnpp
Version: N/A; reported 2017-06-29
Severity: wishlist

* Package name : dpaste
Version : 0.3.3
Upstream Author : Simon Désaulniers <sim.desaulni...@gmail.com>
* URL : https://github.com/sim590/dpaste
* License : GPLv3
Description : A simple pastebin for light values (max 64KB) using OpenDHT
distributed hash table.


-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#866177: [i3lock-fancy] ITP

[Simon Désaulniers]

Subject: ITP: i3lock-fancy -- i3lock custom wrapper script
Package: wnpp
Version: N/A; reported 2017-06-27
Severity: wishlist

* Package name : i3lock-fancy
Version : 20160228.0.0fcb933
Upstream Author : Dolores Portalatin <ad...@doloresportalatin.info>
* URL : https://github.com/meskarune/i3lock-fancy
* License : Expat
Description : i3lock bash script that takes a screenshot of the desktop, blurs
the background and adds a lock icon and text.


-- 
Simon Désaulniers
sim.desaulni...@gmail.com

Bug#866176: [i3lock-fancy] ITP

[Simon Désaulniers]

Package: i3lock-fancy
Version: 20160228.0.0fcb933

-- 
Simon Désaulniers
sim.desaulni...@gmail.com

Bug#743368: alarm-clock-applet: Default installation of alarm-clock-applet does not play sounds.

[Simon Désaulniers]

Hi,

I have managed to solve *my* problem by installing gstreamer1.0-fluendo-mp3.
This should appear in the recommended package list...

-- 
Simon Désaulniers
sim.desaulni...@gmail.com

Bug#743368: alarm-clock-applet: Default installation of alarm-clock-applet does not play sounds.

[Simon Désaulniers]

Hi,

It's been two years since the bug report has been made. I have just installed
the version 0.3.4-1+b1 and it is still the same. Alos, no sound is produced when
the time comes.

The package is simply unusable.

-- 
Simon Désaulniers
sim.desaulni...@gmail.com

Bug#866078: [dhtnode] bump to newer version

[Simon Désaulniers]

Package: libopendht-dev
Version: 1.2.1~dfsg1-8
Severity: normal

Hi,

OpenDHT is now at version 1.3.3. Important new features have been introduced
since 1.2.1 (see [1]). Amongts improvements, there is the following:

- argon2: add support for installed library (still fallback to included sources)
- connecting to loopback address (127.0.0.1) is now supported
- dht: add per-ip-range storage ratio.
- dht: drop values as soon as they expire
- dht: better support for multiple listens on a single hash
- abi: symbols are not exported by default anymore

Upstream is also going to merge an interesting patch for python API~[2]. I
suggest to watch for another subsequent release of this merge.

I also want to emphasis on the fact that python bindings should be provided. I
guess that it is not provided since it would belong in another package called
`python3-opendht` for instance. If so, can you make this package?


[1]: https://github.com/savoirfairelinux/opendht/releases
[2]: https://github.com/savoirfairelinux/opendht/pull/197

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#866075: [dhtnode] ship http_server.py and a systemd associated service

[Simon Désaulniers]

Package: dhtnode
Version: 1.2.1~dfsg1-8
Severity: normal

OpenDHT's upstream has an http server written in python that could find a nice
place in this package. I'm talking about the file:

python/tools/http_server.py

I'd like to use this as a dependency for a debian package of a program I'm
working on~[1]. The program tries to conncet to a local http server which
handles a python dhtnode running behind. I suggest to place the http_server.py
file under /usr/bin/http-dhtnode-server.

Also, the following file from the OpenDHT repository could serve as base for a
systemd service file that could come with http-dhtnode-server so that the server
can be run as a service.

tools/systemd/dhtnode.service.in

Regards,


[1]: https://github.com/sim590/dpaste/

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#855332: linux-image-4.9.0-1-amd64: Fan at max speed on Thinkpad T460s

[Simon Désaulniers]

 SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI 
Express Card Reader [10ec:522a] (rev 01)
Subsystem: Lenovo RTS522A PCI Express Card Reader [17aa:2233]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: rtsx_pci
Kernel modules: rtsx_pci

04:00.0 Network controller [0280]: Intel Corporation Wireless 8260 [8086:24f3] 
(rev 3a)
Subsystem: Intel Corporation Wireless 8260 [8086:0130]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi


** USB devices:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 138a:0090 Validity Sensors, Inc. 
Bus 001 Device 003: ID 5986:0706 Acer, Inc 
Bus 001 Device 002: ID 8087:0a2b Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (750, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.9.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.127
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.2

Versions of packages linux-image-4.9.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.02~beta3-4
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-1-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20161130-2
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#854646: [ranger] sensible-pager patch breaks functionnalities

[Simon Désaulniers]

Package: ranger
Version: 1.8.1-0.1
Tags: important

Hi,

As discussed on upstream's bug trackker[1], using the following patch breaks
some functionnalities:

0002-make-sensible-decisions-on-which-pager-and-editor.patch

For instance, when entering a subshell and calling any program which requires a
pager, we get the error:

/usr/bin/sensible-pager: 3: /usr/bin/sensible-pager: Cannot fork

Regards,


[1]: https://github.com/ranger/ranger/issues/750

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#806977: john: Provide build with "jumbo" patch.

[Simon Désaulniers]

Hi,

Personnaly, I tried your suggestion, but I got the error

E: The repository 'http://http.kali.org/kali/' does not have a Release file

Then, I decided to download the debian packages there:
http://http.kali.org/pool/main/j/john/.

I see that your post is a year old. I find it sad that debian packages are
always so much lagging behind. I have accumulated a pretty big list of such
packages in the past month.

Why has the issue not been addressed for a whole year ?


-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#851942: [mupdf] shell script doesn't understand "--" arg

[Simon Désaulniers]

Package: mupdf
Version: 1.9a+ds1-2
Tags: normal

The shell script shipped with the package doesn't support '--' standard
argument, i.e it will treat it as a file. The shell script could easily be
written to use getopt for shell the script.

I have discovered this because ranger[1] comes shipped with config files that
suggest to call mupdf as

mupdf -- "$@"

I saw that the shell script is part of the debian source package and I can't
find it on the upstream repository[2] so I assume that it was written by the
package maintainer. If not so, can you tell me where I should redirect this bug?

Regards,


[1]: http://ranger.nongnu.org/
[2]: https://github.com/ccxvii/mupdf

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#850701: [awesome] version 4.0 in stretch please

[Simon Désaulniers]

Package: awesome
Version: 3.5.9-1
Tags: wishlist, important

Hi,

Awesome is already in stretch, but is only at version 3.5.9. Upstream is already
at 4.0 and has brought a lot of changes with which the users would like to keep
up with[1][2].

This is important as for instance debian doesn't provide any package for lain[3]
(which is being ported to 4.0). The user then has to manually find the
appropriate version of lain which will be compatible with debian's version of
awesome.

Several bugs in 3.5.9 are fixed in 4.0.

Can you update awesome package to version 4.0 in stretch please?

Regards,


[1]: https://awesomewm.org/apidoc/documentation/89-NEWS.md.html
[2]: https://awesomewm.org/apidoc/documentation/17-porting-tips.md.html
[3]: https://github.com/copycat-killer/lain

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature