Bug#983117: dxvk: failure to apply on a clean prefix, due to a symlink creation issue

[vv221]

Package: dxvk
Version: 1.7.3+ds1-1
Severity: grave
Justification: renders package unusable

Trying to apply dxvk patches on a clean WINE prefix fails with the
following output:

installing dxvk-wine64-development in the wine prefix...
[1/2] Creating override for dxgi
The operation completed successfully
[2/2] Creating link link to dxgi
ln: failed to create symbolic link 
'/tmp/dxvk/wine/dosdevices/c:/windows'$'\r''/system32/dxgi.dll': No such file 
or directory

This issue is systematic since I upgraded wine-development to
repository-provided 5.6-1. It did not happen with the previously
packaged 5.5 version.

The failure happens on both win32 and win64 WINE prefixes.

Installing dxvk using repository-provided winetricks does not seem to be
a valid workaround, as it tries to install DXVK 1.8, that is not
compatible with WINE versions lower than 5.8.

These extra packages versions are probably relevant information:

ii  libwine-development:amd645.6-1amd64Windows API 
implementation - library
ii  libwine-development:i386 5.6-1i386 Windows API 
implementation - library
ii  wine-development 5.6-1all  Windows API 
implementation - standard suite
ii  wine32-development:i386  5.6-1i386 Windows API 
implementation - 32-bit binary loader
ii  wine64-development   5.6-1amd64Windows API 
implementation - 64-bit binary loader

I tried reverting to wine-development 5.5-9 packages, from the snapshots
archive: https://snapshot.debian.org/package/wine-development/5.5-9/
With wine-development 5.5-9, the symlink creation failure does not
happen, and DXVK patches are applied cleanly.

A temporary workaround follows, for other users facing this issue on a
Debian Sid (all commands as root):

cat > /etc/apt/sources.list.d/snapshot-20201026T024334Z.list << EOF
# wine-development 5.5-9
# cf. https://snapshot.debian.org/package/wine-development/5.5-9/
deb [check-valid-until=no] 
https://snapshot.debian.org/archive/debian/20201026T024334Z/ sid main
EOF
apt update
apt install 
{libwine-development:{amd64,i386},wine32-development:i386,wine64-development,wine-development}=5.5-9

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dxvk depends on:
ii  dxvk-wine32-development  1.7.3+ds1-1
ii  dxvk-wine64-development  1.7.3+ds1-1

Versions of packages dxvk recommends:
ii  dxvk-wine32-development  1.7.3+ds1-1
ii  dxvk-wine64-development  1.7.3+ds1-1

dxvk suggests no packages.

-- no debconf information

Bug#982159: dxvk: Dependency on development version of WINE might not be justified

[vv221]

Package: dxvk
Version: 1.7.3+ds1-1
Severity: normal

dxvk currently depends on wine-development being available, or its
patches can not be applied on the target WINE prefix.

In my experience, a WINE prefix patched in this way can then be used
with a stable build of WINE ≥ 5.0. I suspect the dependency on the
development build of WINE was justified when the packaged stable version
of WINE was 4.x, but is no longer useful starting with Bullseye, that is
coming with WINE 5.0.3 stable build.

Since this dependency on wine-development is actually preventing dxvk to
enter testing, I suggest studying the possibility to have it rely on
wine (stable) instead. This is probably a bit late for Bullseye, but
might help for an easier comeback with Bookworm, as well as for Bullseye
backports.

From what I see from the code, it might be as simple as editing the
argument parsing snippet in debian/dxvk-setup/dxvk-setup [1] to drop the
error message and the forced exit.
If this is indeed the case, I can run some tests to ensure it has no
side-effect as long as WINE ≥ 5.0 is available, and submit a patch through
salsa.

[1]: 
https://salsa.debian.org/aviau/dxvk/-/blob/87cda5190382e29bf6bfa2bcc8a487d232b2d073/debian/dxvk-setup/dxvk-setup#L261

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dxvk depends on:
ii  dxvk-wine32-development  1.7.3+ds1-1
ii  dxvk-wine64-development  1.7.3+ds1-1

Versions of packages dxvk recommends:
ii  dxvk-wine32-development  1.7.3+ds1-1
ii  dxvk-wine64-development  1.7.3+ds1-1

dxvk suggests no packages.

-- no debconf information

Bug#969110: gemrb: New upstream release 0.8.7

[vv221]

Source: gemrb
Severity: wishlist

Hello,

The recent 0.8.7 release of GemRB got a lot of attention, due to being
synced with the 20 years of the project (congratulations to all the
team!).

It would be really nice to have access to this new version in Debian Sid
repositories, especially to help getting eyes on the RC issue #936595
and its upstream blocker https://github.com/gemrb/gemrb/issues/95

- 0.8.7 release page on GitHub: 
https://github.com/gemrb/gemrb/releases/tag/v0.8.7
- 0.8.7 release notes: https://gemrb.org/2020/08/24/gemrb-0-8-7-released.html

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Bug#965159: RM: flare -- transition package is a source of confusion

[vv221]

Source: flare
Severity: wishlist
X-Debbugs-Cc: 

The source package flare is used to build two packages: flare and
flare-data. Both of them are transition packages, providing a seamless
upgrade path to the current packages flare-engine and flare-game.

As even Jessie (oldoldstable) already only provided these packages for
transition to the new ones, I think this source package is no longer
useful.

The issue there is by keeping it is that it is a source of confusion: I
have seen Debian users that due to the low version number of this
transition package thought that the current version of the engine and
game were not packaged into Debian, thinking it was no longer
maintained.

To avoid further confusion, I suggest the removal of the flare source
package, and the two binary packages built from it. From a quick check
on a Debian Sid, it does not seem that there is any package currently
depending on these ones.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Bug#883253: ssh-agent.service missing dbus dependency

[vv221]

On Fri, 1 Dec 2017 12:05:55 + Colin Watson  wrote:
> > This should be fixed by adding Wants=dbus.socket and After=dbus.socket to 
> > ssh-agent.service.
> 
> Thanks for the patch; pushed to git master for the next release.

This patch seems to have already been applied quite some time ago.
Is there still a reason to keep this bug report open, or is it only an
oversight?



signature.asc
Description: OpenPGP digital signature

Bug#899138: libopusfile-dev: move opusfile.pc to a multiarch location

[vv221]

Please consider applying the patch submitted by Helmut Grohne if there
is nothing wrong with it, as it is a blocker for issue #935590, and this
one is in turn preventing the co-installation of i386 and amd64 builds
of libsdl2-mixer-2.0-0.

If for some reason the provided patch can not be used in its current
state, I would be happy to help in any way I can to work towards an
acceptable patch.



signature.asc
Description: OpenPGP digital signature

Bug#956508: gitlab: webpack should build assets in production mode

[vv221]

On Sun, 12 Apr 2020 18:04:07 +0530 Pirate Praveen
 wrote:
> On 2020, ഏപ്രിൽ 12 1:56:27 PM IST, vv221  wrote:
> >I submitted a patch through salsa:
> >https://salsa.debian.org/ruby-team/gitlab/-/merge_requests/5
> 
> (…)
> 
> I have merged your changes and I will upload it soon (after some testing).

Such a quick integration is a nice surprise, it is great to know we
should be benefiting from it in the next release.



signature.asc
Description: OpenPGP digital signature

Bug#956508: gitlab: webpack should build assets in production mode

[vv221]

I submitted a patch through salsa:
https://salsa.debian.org/ruby-team/gitlab/-/merge_requests/5

A copy of this patch it attached to this e-mail for convenience.
From 9d95c466b0c26f8cecc3ff6d8a30d608e7a6cf88 Mon Sep 17 00:00:00 2001
From: vv221 
Date: Sun, 12 Apr 2020 10:16:22 +0200
Subject: [PATCH] Build assets generated by webpack in production mode

Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956508
Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927297
---
 debian/rake-tasks.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rake-tasks.sh b/debian/rake-tasks.sh
index 350e4cc98..6545ade34 100755
--- a/debian/rake-tasks.sh
+++ b/debian/rake-tasks.sh
@@ -49,4 +49,5 @@ runuser -u ${gitlab_user} -- sh -c 'cd /usr/share/gitlab/public/assets && \
 
 echo "Webpacking..."
 # Workaround for webpack crashing with nodejs 10 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956211
-runuser -u ${gitlab_user} -- sh -c 'NODE_OPTIONS="--max-old-space-size=2048" webpack --config config/webpack.config.js'
+# Build assets in production mode - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956508
+runuser -u ${gitlab_user} -- sh -c 'NODE_ENV="production" NODE_OPTIONS="--max-old-space-size=4096" webpack --config config/webpack.config.js'
-- 
2.26.0



signature.asc
Description: OpenPGP digital signature

Bug#956508: gitlab: webpack should build assets in production mode

[vv221]

I think a side-effect of using production assets would be to fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927297 as it adds a
unique hash to assets file names.

The hash would be different after each GitLab upgrade, so there should
no longer be cache issues for the GitLab instance users when they visit
it after an upgrade.



signature.asc
Description: OpenPGP digital signature

Bug#956508: gitlab: webpack should build assets in production mode

[vv221]

Source: gitlab
Version: 12.9.2-4
Severity: normal

Current assets building through webpack is done by the following call
set in /usr/lib/gitlab/scripts/rake-tasks.sh:

runuser -u ${gitlab_user} -- sh -c 'NODE_OPTIONS="--max-old-space-size=2048" 
webpack --max-old-space-size=16384 --config config/webpack.config.js'

The issue with this command is that it does not build assets optimized
for use in production, making parts of the GitLab interface heavy on
bandwidth usage, and slow to use on networks with limited bandwidth.

The suggested replacement should fix this issue by explicitely building
assets optimized for production use:

runuser -u ${gitlab_user} -- sh -c 'NODE_ENV="production" 
NODE_OPTIONS="--max-old-space-size=4096" webpack --config 
config/webpack.config.js'

The modifications are:
- Add NODE_ENV="production", this is what triggers the correct assets
  build mode
- Replace NODE_OPTIONS="--max-old-space-size=2048" by
  NODE_OPTIONS="--max-old-space-size=4096", as it seems build in
  production mode uses more memory (an alternative would be to make the
  value configurable in /etc/gitlab/gitlab-debian.conf)
- Drop --max-old-space-size=16384 as it has no effect here, and probably
  was added by mistake while fixing #956211

Thanks to these tweaks, served assets are much smaller and the overall
UI is much more responsive. As an example it takes main.chunk.js from
~25 MB to less than 3MB, before application of gzip compression by
nginx.

For a comparison, both of these GitLab instances use the same GitLab
version based on buster-fasttrack repositories:
- https://gitlab.debian.net/explore - not using the production assets
- https://forge.dotslashplay.it/explore - using the production assets
The difference in responsiveness is easily noticeable, and the
difference is bandwidth usage is important.

Bug#953002: corsix-th: FTBFS with libsdl2 2.0.10+dfsg1-2

[vv221]

On Tue, 3 Mar 2020 08:29:56 + Simon McVittie  wrote:
> I think this is a bug in SDL (#951087, proposed patch:
> ).
> 
> corsix-th might be able to work around it by relying on SDL >= 2.0.4
> providing its own CMake integration (which presumably wasn't available when
> corsix-th's build system was written), similar to
> .
I checked corsix-th building process in a clean Debian Sid chroot (amd64).

With the current libsdl2 build provided in Sid repositories, I reproduce
the failure.

With the proposed patch it builds successfully.
I ran my test using a fresh clone of the proposed patch, HEAD commit is
1ea0dcb76368157f1adfad2493c64595a2ca1d76.



signature.asc
Description: OpenPGP digital signature

Bug#949591: gitlab: Gitlab not serving cached assets

[vv221]

On Wed, 22 Jan 2020 14:43:45 +0100 David L  wrote:
> Apparently, gitlab is not serving cached assets.
> 
> That's result on a very long loading time.
> 
> Example of most relevant file: 
> 
> Cached:
> 
> 304 Not Modified 
> https://salsa.debian.org/assets/webpack/main.b91d0a07.chunk.js <-- 2,55mb, 
> 849ms load time
> 304 Not Modified 
> https://assets.gitlab-static.net/assets/webpack/main.45f98342.chunk.js <-- 
> 0b, 42ms load time
> 
> My installation:
> 
> 200 OK https://git.myserver.net/assets/webpack/main.chunk.js <-- 20.87mb, 
> 12135ms load time

I think this is due to the environment variable NODE_ENV not being set
to "production" when the assets building command is called.

I’m currently experimenting a bit to find a way to reliably pass this
variable to any rake command, but in the meantime it would be nice to
know if the maintainers team has some advice on this front.



signature.asc
Description: OpenPGP digital signature

Bug#942515: gitlab: Missing package in buster-backports / buster-fasttrack

[vv221]

(original reporter here)

My bad, I totally missed the launch of official Fast Track repositories.
Thanks for the quick answer, this bug report can be closed.



signature.asc
Description: OpenPGP digital signature

Bug#891319: error: module, invalid directory '/usr/lib/x86_64-linux-gnu/knot'

[vv221]

Package: knot
Version: 2.6.5-1
Severity: grave
Justification: renders package unusable

After upgrade from 2.6.4-1 to 2.6.5-1, knot fails to start as a service
with the following errors:

error: module, invalid directory '/usr/lib/x86_64-linux-gnu/knot'
critical: failed to open configuration database '' (invalid parameter)

With version 2.6.5-1 the directory /usr/lib/x86_64-linux-gnu/knot does not
exist.
With version 2.6.4-1 this directory exists but is empty.

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages knot depends on:
ii  adduser 3.117
ii  libc6   2.26-6
ii  libdnssec5  2.6.5-1
ii  libedit23.1-20170329-1
ii  libfstrm0   0.3.0-1+b1
ii  libgnutls30 3.5.18-1
ii  libknot72.6.5-1
ii  libprotobuf-c1  1.2.1-2
ii  libsystemd0 237-3
ii  liburcu60.10.1-1
ii  libzscanner12.6.5-1
ii  lsb-base9.20170808
ii  python3 3.6.4-1
ii  python3-yaml3.12-1+b1

Versions of packages knot recommends:
pn  python3-lmdb  

Versions of packages knot suggests:
ii  systemd  237-3

-- no debconf information

Bug#872539: qt5-style-plugins: fails to install on Sid

[vv221]

Package: qt5-style-plugins
Version: 5.0.0+git23.g335dbec-2
Severity: grave
Justification: renders package unusable

Hi!
Since qt5 in Debian Sid got updated to 5.9, qt5-style-plugins is no
longer installable due to its dependency on qtbase-abi-5-7-1 that is no
longer provided.

Here is what I get from APT when I try to install it on a fresh Sid:

root@HAL9000:~# apt install qt5-style-plugins
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 qt5-style-plugins : Depends: qtbase-abi-5-7-1 but it is not installable
 E: Unable to correct problems, you have held broken packages.


On a Debian Sid with Qt 5.7, qt5-style-plugins will block the upgrade of
qt5 packages to 5.9 unless you remove it prior to upgrading. If you use
'full-upgrade' it will be automatically removed during the upgrade, so
this is not a "hard" blocker.

I assigned a severity of 'grave' to this report because the package is
no longer installable on a freshly installed Sid, feel free to lower the
severity if you don’t think this is enough to warrant this high
severity.

Thanks in advance for looking into this, and please tell me if I can do
anything to help resolve this issue ;)

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qt5-style-plugins depends on:
ii  libc62.24-14
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.53.4-3
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.9-1
ii  libqt5core5a [qtbase-abi-5-7-1]  5.7.1+dfsg-4
ii  libqt5dbus5  5.7.1+dfsg-4
ii  libqt5gui5   5.7.1+dfsg-4
ii  libqt5widgets5   5.7.1+dfsg-4
ii  libstdc++6   7.1.0-13
ii  libx11-6 2:1.6.4-3

qt5-style-plugins recommends no packages.

qt5-style-plugins suggests no packages.

-- no debconf information

Bug#801671: support Quake3 GOG package

[vv221]

No more multiple calls to innoextract since commit
d6d0d7451020be2fb632fc86ea82b3b207f8b9b6 (quake3: fix
Help/DedicatedServer.html alternative)
The build now goes fine from beginning to end with the GOG installer.

Well done Alexandre ;)

Bug#801671: support Quake3 GOG package

[vv221]

On Tue, 13 Oct 2015 22:43:58 +0200 Alexandre Detiste
 wrote:
> game-data-packager should now support the GOG release.
> 
> Can you test ?

There seems to be a problem with the GOG version support by git version
of g-d-p. It extracts the game data, identifies two pak0.pk3 files, but
then loops back: archive extraction again, .pk3 files identification, etc.

I put a copy of my console returns in the attached g-d-p_quake3.log
file. I had to interrupt the process via Ctrl+C, or I guess it would
have kept looping indefinitely.

> There's also this ...
>   167   e2fd03b57cd200b571849f7ac0f5178c baseq3/q3key
> does that means that all GOG users share the same "unique" serial ?

That’s right as far as I know.
I guess any game owner can request a really unique serial from GOG.
dave@HAL9000:~/bureau/game-data-packager$ ./run -n -d ./quake3/ --no-compress quake3 ~/jeux/quake-3/archives/gog/setup_quake3_2.0.0.2.exe 
INFO:game-data-packager.build:identifying /home/dave/jeux/quake-3/archives/gog/setup_quake3_2.0.0.2.exe
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/missionpack/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/baseq3/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/missionpack/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/baseq3/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/missionpack/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/baseq3/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/missionpack/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/baseq3/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/missionpack/pak0.pk3
INFO:game-data-packager.build:identifying /tmp/gdptmp.kkwrdnh6/tmp/setup_quake3_2.0.0.2.exe.d/app/baseq3/pak0.pk3

Bug#791758: redshift: cursor is unaffected

[vv221]

This is a known upstream limitation: hardware cursor is not affected by
redshift (at least with randr method, the default).
It is actually stated on the official website:
http://jonls.dk/redshift/
(search for "Known bugs and limitations")

A workaround would be to use software cursor, here is what I have to add
to the "Device" section of my xorg.conf to achieve this ('radeon' driver):

Option  "SWCursor"  "on"

But a real fix would be nice, seeing as some applications do not behave
as intended with software cursor enabled.

Bug#800622: game-data-packager: Quake 2 & 3 (GOG), make-template output

[vv221]

Le 02/10/2015 08:22, Alexandre Detiste a écrit :
> There's also music/track02.ogg till music/track21.ogg
> where quake2-music expect 
> /usr/share/games/quake2/baseq2/music/02.ogg
> /usr/share/games/quake2/baseq2/music/03.ogg
> /usr/share/games/quake2/baseq2/music/04.ogg
> /usr/share/games/quake2/baseq2/music/05.ogg
> /usr/share/games/quake2/baseq2/music/06.ogg
> /usr/share/games/quake2/baseq2/music/07.ogg
> /usr/share/games/quake2/baseq2/music/08.ogg
> /usr/share/games/quake2/baseq2/music/09.ogg
> /usr/share/games/quake2/baseq2/music/10.ogg
> /usr/share/games/quake2/baseq2/music/11.ogg
>
> The extra files would map somehow to some tracks of these two CD's;
> (& some track are re-used on several CD too):
>
> http://musicbrainz.org/release/a1eb0af4-6348-4aa6-a586-4f41a33c5dea
> http://musicbrainz.org/release/7590e38c-f203-425a-b726-37a55b6d2937
I listened to Ground Zero and The Reckoning soundtracks online, and it
appears that track12.ogg to track21.ogg map to the Ground Zero
soundtrack as described here:
https://musicbrainz.org/release/7590e38c-f203-425a-b726-37a55b6d2937

Bug#796127: rox-filer: add rox-filer to the 'x-session-manager' alternatives

[vv221]

Package: rox-filer
Version: 1:2.11-1
Severity: wishlist

Hi!

rox-filer, if launched with the '--rox-session' option, can handle a desktop
session. So it would be nice if we could chose it via 'update-alternatives
--config x-session-manager' without the need to add it to the alternatives
list first.
I guess it would need a new binary 'rox-session' that would call 'rox
--rox-session' (actually a shell script should be okay for this).

Please tell me if you are okay with the idea, and I’ll try to write a patch
adding this feature.
Even if it looks like something nearly trivial, it might take me some time
considering I’ve yet to learn how to write such a patch, but I have enough
free time and motivation to take care of this feature ;)


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'unstable'), (800, 'testing'), 
(800, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rox-filer depends on:
ii  libc6   2.19-19
ii  libgdk-pixbuf2.0-0  2.31.5-1
ii  libglib2.0-02.44.1-1.1
ii  libgtk2.0-0 2.24.28-1
ii  libice6 2:1.0.9-1+b1
ii  libpango-1.0-0  1.36.8-3
ii  libsm6  2:1.2.2-1+b1
ii  libx11-62:1.6.3-1
ii  libxml2 2.9.2+dfsg1-3
ii  shared-mime-info1.3-1

Versions of packages rox-filer recommends:
pn  zeroinstall-injector  none

Versions of packages rox-filer suggests:
ii  file  1:5.22+15-2
ii  menu  2.1.47

-- no debconf information

Bug#793249: innoextract: change of type in system_error might break with GCC-5

[vv221]

I just successfully built innoextract 1.4-1 from the Debian source in a
Sid chroot with GCC 5, and tested the resulting binary on an InnoSetup
installer, with success again.

I do not have the basic knowledge to understand the given
wiki.debian.org link, so I might be missing something obvious, but it
seems to me that innoextract is actually compatible with GCC 5.

innoextract is heavily used in one of my current projects, so tell me if
I can do anything to help on this matter ;)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784953: freespace2: fails to download fs2_ogg.zip

[vv221]

 Both url works, but I guess they also both can't be deep-linked
 if freespacemods.net hasn't seen your IP addresse recently
 or something.
I just gave it a try, and you’re right: a simple wget -O fs2_ogg.zip
http://www.freespacemods.net/request.php?128; does start the download
without the 403 error I’ve been experiencing prior to visiting the website.
But a subsequent try with game-data-packager does end up with a 403
error again (from the same session, same IP). I gave it another try
after editing the freespace2.json file to use the alternative URL, but
had no better luck (still failing on a 403 error).

Looks like the URL has nothing to do with the 403 error after all, there
might be something going wrong with the way game-data-packager tries to
download this file.

 Someone else with an IP not in cache must try
 wget http://www.freespacemods.net/e107_files/downloads/fs2_ogg.zip;
 to be sure.
I’ll have access to another IP later today, so I’ll check this and report.

 If both urls require that the website had been visited,
 this could be maybe worked  around with wkhtmltopdf
 or lynx -dump  /dev/null or something; but that
 would be considered abuse.
 I can't host such hug file myself either.

 I guess the only solution then is to disable
 the automatic upload and move the URL to the help text.
One workaround I can think of is the one used by winetricks when it
needs a file that can’t be downloaded without the user doing it manually
from some website: it interrupts its process, gives the URL of the page
from which to download the file, and a local directory it should be
saved to. After downloading the file and putting it in the right place,
the next execution of the script will find the file and process it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784952: freespace2: fails to download FS2.bmp

[vv221]

Package: game-data-packager
Version: 41
Severity: normal

Part of the building process of the .deb for freespace2 includes the 
downloading of a FS2.bmp file.
The script uses a wrong URL, resulting in the following error:

INFO:game-data-packager:downloading 
http://anonscm.debian.org/cgit/users/onlyjob/freespace2.git/tree/debian/packages/freespace2-data-gog/debian/FS2.bmp
WARNING:game-data-packager:found possible FS2.bmp
but its size does not match:
  file: /tmp/gdptmp.wpc65w2t/tmp/FS2.bmp
  expected: 86070 bytes
  found   : 573138 bytes

The following URL should allow to download the right FS2.bmp file:
https://anonscm.debian.org/cgit/users/onlyjob/freespace2.git/plain/debian/packages/freespace2-data-gog/debian/FS2.bmp

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'unstable'), (800, 'testing'), 
(800, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages game-data-packager depends on:
ii  fakeroot1.20.2-1
ii  python3 3.4.2-2
ii  python3-debian  0.1.27
ii  python3-yaml3.11-2
pn  python3:any none

game-data-packager recommends no packages.

Versions of packages game-data-packager suggests:
pn  arjnone
ii  binutils   2.25-7
ii  cabextract 1.6-1
ii  cdparanoia 3.10.2+debian-11
pn  dynamite   none
ii  gcc4:4.9.2-3
pn  gir1.2-gtk-3.0 none
pn  gir1.2-pango-1.0   none
ii  innoextract1.4-1+b1
pn  lgc-pg none
pn  lhasa | jlha-utils | lzh-archiver  none
ii  make   4.0-8.1
ii  p7zip-full 9.20.1~dfsg.1-4.1
pn  python3-gi none
pn  unace-nonfree  none
pn  unrar-nonfree  none
ii  unshield   1.0-1
ii  unzip  6.0-16
ii  vorbis-tools   1.4.0-6

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784953: freespace2: fails to download fs2_ogg.zip

[vv221]

Package: game-data-packager
Version: 41
Severity: normal

Due to a wrong URL in the script for freespace2, game-data-packager fails to 
download the fs2_ogg.zip file,
which in turn cancels the build of the freespace2-video package:

WARNING:game-data-packager:Failed to download 
http://www.freespacemods.net/request.php?128: HTTP Error 403: Forbidden
ERROR:game-data-packager:Failed to download necessary files for freespace2-video

The following URL should allow the direct download of the file:
http://www.freespacemods.net/e107_files/downloads/fs2_ogg.zip

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'unstable'), (800, 'testing'), 
(800, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages game-data-packager depends on:
ii  fakeroot1.20.2-1
ii  python3 3.4.2-2
ii  python3-debian  0.1.27
ii  python3-yaml3.11-2
pn  python3:any none

game-data-packager recommends no packages.

Versions of packages game-data-packager suggests:
pn  arjnone
ii  binutils   2.25-7
ii  cabextract 1.6-1
ii  cdparanoia 3.10.2+debian-11
pn  dynamite   none
ii  gcc4:4.9.2-3
pn  gir1.2-gtk-3.0 none
pn  gir1.2-pango-1.0   none
ii  innoextract1.4-1+b1
pn  lgc-pg none
pn  lhasa | jlha-utils | lzh-archiver  none
ii  make   4.0-8.1
ii  p7zip-full 9.20.1~dfsg.1-4.1
pn  python3-gi none
pn  unace-nonfree  none
pn  unrar-nonfree  none
ii  unshield   1.0-1
ii  unzip  6.0-16
ii  vorbis-tools   1.4.0-6

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org