Bug#1072448: rbdoom3bfg: FTBFS with ffmpeg 7.0
Dear Maintainer,
Please find in attachment a patch that you can drop in the
debian/patches/ directory to fix the build with ffmpeg 7
Best regards,
Sébastien
Description: fix build with ffmpeg 7
Forwarded: Committed upstream
cherry picked from:
- 78c5fd3a8c13fdb720875fd3051097e4acd018b6
- 21b021c3c01d9951f7996bd551de2869c3368c77
--- a/neo/renderer/Cinematic.cpp
+++ b/neo/renderer/Cinematic.cpp
@@ -619,6 +619,7 @@ bool idCinematicLocal::InitFromFFMPEGFil
int ret;
int ret2;
int file_size;
+ char error[64];
looping = amilooping;
startTime = 0;
isRoQ = false;
@@ -688,8 +689,7 @@ bool idCinematicLocal::InitFromFFMPEGFil
dec_ctx = avcodec_alloc_context3( dec );
if( ( ret = avcodec_parameters_to_context( dec_ctx, fmt_ctx->streams[video_stream_index]->codecpar ) ) < 0 )
{
- char* error = new char[256];
- av_strerror( ret, error, 256 );
+ av_strerror( ret, error, sizeof( error ) );
common->Warning( "idCinematic: Failed to create video codec context from codec parameters with error: %s\n", error );
}
dec_ctx->time_base = fmt_ctx->streams[video_stream_index]->time_base;
@@ -698,8 +698,7 @@ bool idCinematicLocal::InitFromFFMPEGFil
/* init the video decoder */
if( ( ret = avcodec_open2( dec_ctx, dec, NULL ) ) < 0 )
{
- char* error = new char[256];
- av_strerror( ret, error, 256 );
+ av_strerror( ret, error, sizeof( error ) );
common->Warning( "idCinematic: Cannot open video decoder for: '%s', %d, with error: %s\n", qpath, looping, error );
return false;
}
@@ -712,8 +711,7 @@ bool idCinematicLocal::InitFromFFMPEGFil
dec_ctx2 = avcodec_alloc_context3( dec2 );
if( ( ret2 = avcodec_parameters_to_context( dec_ctx2, fmt_ctx->streams[audio_stream_index]->codecpar ) ) < 0 )
{
- char* error = new char[256];
- av_strerror( ret2, error, 256 );
+ av_strerror( ret2, error, sizeof( error ) );
common->Warning( "idCinematic: Failed to create audio codec context from codec parameters with error: %s\n", error );
}
dec_ctx2->time_base = fmt_ctx->streams[audio_stream_index]->time_base;
@@ -727,8 +725,12 @@ bool idCinematicLocal::InitFromFFMPEGFil
if( dec_ctx2->sample_fmt >= AV_SAMPLE_FMT_U8P ) // SRS - Planar formats start at AV_SAMPLE_FMT_U8P
{
dst_smp = static_cast( dec_ctx2->sample_fmt - AV_SAMPLE_FMT_U8P ); // SRS - Setup context to convert from planar to packed
- swr_ctx = swr_alloc_set_opts( NULL, dec_ctx2->channel_layout, dst_smp, dec_ctx2->sample_rate, dec_ctx2->channel_layout, dec_ctx2->sample_fmt, dec_ctx2->sample_rate, 0, NULL );
- int res = swr_init( swr_ctx );
+ if( ( ret2 = swr_alloc_set_opts2( _ctx, _ctx2->ch_layout, dst_smp, dec_ctx2->sample_rate, _ctx2->ch_layout, dec_ctx2->sample_fmt, dec_ctx2->sample_rate, 0, NULL ) ) < 0 )
+ {
+av_strerror( ret2, error, sizeof( error ) );
+common->Warning( "idCinematic: Failed to create audio resample context with error: %s\n", error );
+ }
+ ret2 = swr_init( swr_ctx );
hasplanar = true;
}
else
@@ -736,7 +738,7 @@ bool idCinematicLocal::InitFromFFMPEGFil
dst_smp = dec_ctx2->sample_fmt; // SRS - Must always define the destination format
hasplanar = false;
}
- common->Printf( "Cinematic audio stream found: Sample Rate=%d Hz, Channels=%d, Format=%s, Planar=%d\n", dec_ctx2->sample_rate, dec_ctx2->channels, GetSampleFormat( dec_ctx2->sample_fmt ), hasplanar );
+ common->Printf( "Cinematic audio stream found: Sample Rate=%d Hz, Channels=%d, Format=%s, Planar=%d\n", dec_ctx2->sample_rate, dec_ctx2->ch_layout.nb_channels, GetSampleFormat( dec_ctx2->sample_fmt ), hasplanar );
cinematicAudio->InitAudio( dec_ctx2 );
}
else
@@ -1310,6 +1312,7 @@ idCinematicLocal::ImageForTimeFFMPEG
cinData_t idCinematicLocal::ImageForTimeFFMPEG( int thisTime )
{
cinData_t cinData;
+ char error[64];
uint8_t* audioBuffer = NULL;
int num_bytes = 0;
@@ -1404,16 +1407,14 @@ cinData_t idCinematicLocal::ImageForTime
// Decode video frame
if( ( res = avcodec_send_packet( dec_ctx, ) ) != 0 )
{
- char* error = new char[256];
- av_strerror( res, error, 256 );
+ av_strerror( res, error, sizeof( error ) );
common->Warning( "idCinematic: Failed to send video packet for decoding with error: %s\n", error );
}
else
{
if( ( frameFinished = avcodec_receive_frame( dec_ctx, frame ) ) != 0 )
{
- char* error = new char[256];
- av_strerror( frameFinished, error, 256 );
+ av_strerror( frameFinished, error, sizeof( error ) );
common->Warning( "idCinematic: Failed to receive video frame from decoding with error: %s\n", error );
}
}
@@ -1424,22 +1425,20 @@ cinData_t idCinematicLocal::ImageForTime
res = avcodec_send_packet( dec_ctx2, );
if( res != 0 && res != AVERROR( EAGAIN ) )
{
- char* error = new char[256];
- av_strerror( res, error, 256 );
+ av_strerror( res, error, sizeof( error ) );
common->Warning( "idCinematic: Failed to send audio packet
Bug#1072226: RFS: serious-engine/0~git20230724+dfsg-1 [ITP]
control: tags 1072226 - moreinfo Le vendredi 31 mai 2024 à 10:11 +0200, Gianfranco Costamagna a écrit : > control: tags -1 moreinfo > > Hello, some copyright/licenses are missing > > GPL-3+ > Sources/Ecc/Parser.cpp: GNU General Public License v3.0 or later > Sources/Ecc/Parser.h: GNU General Public License v3.0 or later > Sources/Ecc/Parser.hpp: GNU General Public License v3.0 or later > > Sources/Engine/Base/Parser.cpp: GNU General Public License v3.0 or > later > Sources/Engine/Base/Parser.h: GNU General Public License v3.0 or > later > Sources/Engine/Base/Parser.hpp: GNU General Public License v3.0 or > later > > Sources/Engine/Ska/smcPars.cpp: GNU General Public License v3.0 or > later > Sources/Engine/Ska/smcPars.h: GNU General Public License v3.0 or > later > Sources/Engine/Ska/smcPars.hpp: GNU General Public License v3.0 or > later Hi, i'm sorry but... all those files aren't present in the orig tarball ! They are generated during the build by Bison. I will not add artefact generated by the build system to d/copyrigth, that would be insane... > GPL-2+ > Sources/Ecc/parser.h: GNU General Public License v2.0 or later > Sources/Engine/Base/parser.h: GNU General Public License v2.0 or > later > those 2 were already fixed in the last upload in the 2023-05-28 br, Sébastien > And probably more > > Please remove moreinfo tag once you address the above > > Cheers > > Gianfranco > (a serious serious sam fan!)
Bug#1072226: RFS: serious-engine/0~git20230724+dfsg-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "serious-engine": * Package name : serious-engine Version : 0~git20230724+dfsg-1 Upstream contact : https://github.com/ptitSeb/Serious-Engine/issues * URL : https://www.croteam.com/serious-sam-source-code-released/ * License : GPL-2 * Vcs : https://salsa.debian.org/twolife/serious-engine Section : contrib/games The source builds the following binary packages: serious-sam-tfe - Serious Sam - The First Encounter serious-sam-tse - Serious Sam - The Second Encounter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/serious-engine/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/s/serious-engine/serious-engine_0~git20230724+dfsg-1.dsc Changes for the initial release: serious-engine (0~git20230724+dfsg-1) unstable; urgency=low . * Initial release. Closes: #1034630 This package alone isn't of any use; it only contains the game engine, an engine that has no Free data and therefore is in contrib. You will need a copy of the original game for this package to be useful. Please use game-data-packager to build a .deb of proprietary data (gog or steam) to unleash the full potential of this code. Best Regards, Sébastien
Bug#911189: gpgme-json packaging
On Fri, 17 May 2024 11:36:00 + Detlef Eppers wrote: > That said: naming is important and naming is hard, but three years > have passed, and it is my impression that this is getting somewhat > out of proportion. +1 i have been building my own gpgme packages for the last 5+ years because of all the indecision & nitpicking. If it helps, here is an updated branch: https://salsa.debian.org/twolife/gpgme/-/commits/gpgmejson details: - i put the gpgme-json binary in a new 'gpgme-bin' package and not 'libgpgme-dev' as this is not a dev/debug/test utilitie - the browser manifests are shipped in the same package, a 5 lines json file doesn't justify the overhead of splitting it in another package - thanks to Sascha Wilde for the manpage i stoled in the previous MR i have the feeling i'm sending this email to /dev/null :'( graybeards blocking progress because "this is my sacred garden that young fools will not taint" is unfortunately pretty common in debian land :'(
Bug#1052371: game-data-packager: a crash while rebuilding quake2-full-data deb package
On Thu, 21 Sep 2023 08:29:24 +0300 undef wrote: > Package: game-data-packager > Version: 63 > Severity: normal > > Dear Maintainer, > when I tried to build quake2-full-data from the existing deb package > gdb crashed > >[..] I was able to easily reproduce the crash. A fix could be as simple as --- a/game_data_packager/build.py +++ b/game_data_packager/build.py @@ -903,7 +903,7 @@ class PackagingTask: if provider is None: try_to_unpack: Collection[str] = self.game.files should_provide = set() -distinctive_dirs = False +distinctive_dirs = True else: try_to_unpack = set(f.name for f in provider.provides_files) should_provide = set(try_to_unpack) but i'm not familiar enough with that part of the code to have a full view of the implications of that change... Context: - the file provided on the CLI is "unknown/untrusted" by g-d-p and so there isn't any "provider" for the stream and for that case, 'distinctive_dirs' was set to False (what's the reasoning for that ?) - quake2 have multiple (different) gamefiles that have the same basename() - the way we loop through the files in the unpacker and the gamefiles lead to a tentative to seek backward when 'distinctive_dirs' is False (we tries to extract dir1/file.md2 instead of dir2/file.md2) I don't know why we should treat "unknown" stream with 'distinctive_dirs = False' by default, but maybe I'm missing something? br, Sébastien
Bug#1059449: game-data-packager: Fate of Atlantis fails to start without "scumm:" prefix
On Wed, 27 Dec 2023 14:18:25 +0100 Alexandre Detiste wrote: > [...] > So actually (option a) the .desktop file would looks like this: > > > +Exec=/usr/share/games/game-data-packager[runtime] fate-of- atlantis-en-data > > _or_ (option b) game-data-packager-runtime would ship .desktop files > pre-generated for each game but that would mean spamming > the various desktop environments with so many TryExec= > and I don't know if they would cope > > I prefer option a. option 'a' would implies that g-d-p-runtime has access to g-d-p data to make the magic happen; a dependency we don't currently have [option c proposal] pre-generated .desktop files shipped in game-data-packager-runtime at a unusual place & a symlink in the generated .deb's to activate it (but i don't like it more than option 'a' ^^) br, Sébastien
Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.
Hi Florian, Le 2024-01-14 13:51, Florian Schlichting a écrit : Hi Sébastien, thank you for the patch. I'm not opposed to applying it. In my superficial testing, it seems to work well. I'm not a user of yubioath-desktop, though, and while I can help with an occasional upload, I don't want to feel responsible for it. Are you able to keep an eye on yubioath-desktop in Debian and, if necessary, respond to upcoming issues? for what it's worth, i have been running yubioath with this patch for ~11 months, so I would feel confident to ship it in Debian and take responsibility for it Do you want to submit your patch upstream, so that we can see what they think, and other distributions can find your work? Upstream doesn't seems interested; all they do on github is to tag issue/mr about the old codebase with the 'legacy' label & close the issue. my patches are available here: https://github.com/twolife/yubioath-desktop-legacy/ Florian br, Sébastien
Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.
On Sat, 13 Jan 2024 11:26:50 +0100 Florian Schlichting
wrote:
>
> [...]
> While it might be possible to patch py/yubikey.py to work with the
> interface changes in current python3-ykman, I doubt this is a
> sensible thing to do if upstream has decided to abandon
> the QT version.
in case you are interested, you can find the patch in attachement
br,
Sébastien
From 5660af2838fef22b53e9c7c47381755e96dcdc52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Noel?=
Date: Sat, 25 Feb 2023 17:59:48 +0100
Subject: [PATCH] Compatibility for ykman 5
---
py/yubikey.py | 93 ++-
1 file changed, 84 insertions(+), 9 deletions(-)
diff --git a/py/yubikey.py b/py/yubikey.py
index 592f215..bfec19b 100644
--- a/py/yubikey.py
+++ b/py/yubikey.py
@@ -20,9 +20,7 @@
from fido2.ctap import CtapError
from fido2.ctap2 import Ctap2, ClientPin, FPBioEnrollment, CredentialManagement, CaptureError
-from ykman.device import scan_devices, list_all_devices, connect_to_device, get_name, read_info
from ykman.pcsc import list_readers, list_devices as list_ccid
-from ykman.otp import PrepareUploadFailed, generate_static_pw, prepare_upload_key, time_challenge, format_oath_code
from ykman.settings import AppData
from ykman.oath import is_hidden, is_steam, calculate_steam
from ykman.scancodes import KEYBOARD_LAYOUT, encode
@@ -44,6 +42,18 @@
import pyotherside
+from ykman import __version__ as ykman_v
+
+if int(ykman_v.split(".")[0] ) > 4:
+from yubikit.support import get_name, read_info
+from ykman.device import list_all_devices, scan_devices
+from ykman.otp import (
+_PrepareUploadFailed as PrepareUploadFailed
+, _prepare_upload_key as prepare_upload_key, generate_static_pw, time_challenge, format_oath_code)
+else:
+from ykman.device import scan_devices, list_all_devices, get_name, read_info
+from ykman.otp import PrepareUploadFailed, generate_static_pw, prepare_upload_key, time_challenge, format_oath_code
+
logger = logging.getLogger(__name__)
@@ -193,7 +203,22 @@ def _open_device(self, connection_types=[SmartCardConnection, FidoConnection, Ot
return dev.open_connection(connection_types[0])
else:
raise ValueError('no_device_custom_reader')
-return connect_to_device(self._current_serial, connection_types=connection_types)[0]
+
+if int(ykman_v.split(".")[0] ) > 4:
+devs = list_all_devices(connection_types)
+if len(devs) == 0:
+raise Exception("No YubiKey connected")
+elif len(devs) != 1:
+raise Exception("More than one YubiKey connected")
+dev, info2 = devs[0]
+
+for conn_type in connection_types:
+try:
+return dev.open_connection(conn_type)
+except Exception:
+logger.debug(f"Failed connecting to the YubiKey over {conn_type}", exc_info=True)
+else:
+return connect_to_device(self._current_serial, connection_types=connection_types)[0]
def _open_oath(self):
if self._reader_filter:
@@ -203,7 +228,16 @@ def _open_oath(self):
else:
raise ValueError('no_device_custom_reader')
-return connect_to_device(self._current_serial, [SmartCardConnection])[0]
+if int(ykman_v.split(".")[0] ) > 4:
+devs = list_all_devices([SmartCardConnection])
+if len(devs) == 0:
+raise Exception("No YubiKey connected")
+elif len(devs) != 1:
+raise Exception("More than one YubiKey connected")
+dev, info2 = devs[0]
+return dev.open_connection(SmartCardConnection)
+else:
+return connect_to_device(self._current_serial, [SmartCardConnection])[0]
def is_win_non_admin(self):
return success({'winNonAdmin': self._win_non_admin})
@@ -284,7 +318,39 @@ def _get_version(dev):
supported_interfaces = interfaces_from_capabilities(
info.supported_capabilities.get(TRANSPORT.USB))
-return {
+if int(ykman_v.split(".")[0] ) > 4:
+ return {
+'name': get_name(info, dev.pid.yubikey_type),
+'version': _get_version(info),
+'serial': info.serial or '',
+'usbAppEnabled': [
+a.name for a in CAPABILITY
+if a in info.config.enabled_capabilities.get(TRANSPORT.USB)],
+'usbAppSupported': [
+a.name for a in CAPABILITY
+if a in info.supported_capabilities.get(TRANSPORT.USB)],
+'nfcAppEnabled': [
+a.name for a in CAPABILITY
+if a in info.config.enabled_capabilities.get(TRANSPORT.NFC, [])],
+'nfcAppSupported': [
+a.name for a in CAPABILITY
+if a in info.supported_capabilities.get(TRANSPORT.NFC, [])],
+
Bug#1051803: ITS: freespace2
Ping ? Le mercredi 20 septembre 2023 à 10:04 +0200, Sébastien Noel a écrit : > Hi Dmitry ! > > Le 2023-09-19 05:06, Dmitry Smirnov a écrit : > > I still have interest for this package but I'm struggling with > > limited > > capacity and more pressing priorities. I'd appreciate some help and > > you > > are welcome to co-maintain the package. > > > > Thank you for your attention and care. > > Glad to read that you are still interested to maintain freespace2 :-) > And I'm more than willing to co-maintain the package with you! > As mentioned in my email, I have pushed changes to salsa [1] > and have uploaded a "ready to use" package on m.d.n [2] ; > I would really appreciate if you could find time to review those > changes > and get back to me :-) > > I'm going to close this ITS > > Best regards, > Sébastien > > [1] https://salsa.debian.org/onlyjob/freespace2/-/merge_requests/1 > [2] https://mentors.debian.net/package/freespace2/
Bug#1051803: ITS: freespace2
Hi Dmitry ! Le 2023-09-19 05:06, Dmitry Smirnov a écrit : I still have interest for this package but I'm struggling with limited capacity and more pressing priorities. I'd appreciate some help and you are welcome to co-maintain the package. Thank you for your attention and care. Glad to read that you are still interested to maintain freespace2 :-) And I'm more than willing to co-maintain the package with you! As mentioned in my email, I have pushed changes to salsa [1] and have uploaded a "ready to use" package on m.d.n [2] ; I would really appreciate if you could find time to review those changes and get back to me :-) I'm going to close this ITS Best regards, Sébastien [1] https://salsa.debian.org/onlyjob/freespace2/-/merge_requests/1 [2] https://mentors.debian.net/package/freespace2/
Bug#986740: forked-daapd : please package new upstream release
Le 2023-09-16 18:06, Bastian Germann a écrit : I am happy to review and sponsor your upload. Please add yourself as Uploader and keep it in the Multimedia Team. Also, please rename the binary package to owntone. There is a Debian package available from upstream: https://github.com/owntone/owntone-apt Maybe you can use parts of it. Thank you for the proposal. I already have made the ajustements to upgrade forked-daap to the newest owntone release, but I'm not happy with it, and after a long thought I think it's best to simply removed the software from the Debian archive. The software in Debian is currently crippled due to the impossibility to rebuild the web interface (based on the Vue.js framework with, as usual in the JS world, a "not small" dependency tree). The proper way of dialing with this (ie packaging all the missing javascript modules) is more of a crusade than a weekend project. I consider that shipping a software without half of the functionalities is a disservice to our users, and an "insult" to upstream developer. Upstream has already a pipeline that produce a complete package, we should not pretend that we are doing better than them, specifically if all we can deliver is a broken version. Best regards, Sébastien
Bug#1051803: ITS: freespace2
Source: freespace2 Version: 3.7.4+repack-1.1 Severity: important X-Debbugs-CC: pkg-games-de...@lists.alioth.debian.org Dear maintainer, After looking at your freespace2 package [1], I found that this package received no maintainer updates in the past 5 years and was not in good shape. It has a FTBFS bug [2] and it was removed from testing 6 months ago. As a result, I am filing an ITS (Intent to Salvage) request against your package according to section 5.12 in Debian's Developers' Reference [1]. My current plan to maintain the package under the umbrella of the Debian Games Team, to package the latest upstream release, clean up packaging and review/fix all Debian bug reports. A MR has already been posted to Salsa [3] Full disclosure: I will need a sponsor to upload the package in the archive. Please let me know whether you are still willing to maintain this package. If you find it necessary to pause the ITS process, please let me know immediately by replying this bug report. [1] https://tracker.debian.org/pkg/freespace2 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012232 [3] https://salsa.debian.org/onlyjob/freespace2/-/merge_requests/1
Bug#1051321: kodi-game-libretro: please provide virtual libretro-frontend
Package: kodi-game-libretro Version: 20.2.4-1 There is currently no way to install libretro cores without installing another frontend like retroarch, even if I only want to use Kodi. A simple "Provides: libretro-frontend" to the kodi-game-libretro package should do the trick. I already provided a Salsa MR 6 months ago, but without a proper report here I suppose nobody was notified https://salsa.debian.org/games-team/libretro/kodi-game-libretro/-/merge_requests/1 Regards, Sébastien
Bug#1050497: incompatible with the current gnome-shell version
Package: gnome-shell-extension-dashtodock Version: 87-1 Severity: serious Dear maintainer, The last version you uploaded to sid (87) is incompatible with the gnome-shell version available in unstable (44) This render your package completely unusable. The last dashtodock version compatible with g-s 44 is v84 Regards, Sébastien
Bug#1050414: Please build audacious against Qt6 instead of Qt5
Package: audacious Version: 4.3.1-1~exp1 Severity: wishlist Dear maintainer, Qt5 is on life support and the Qt6 front-end of audacious works great. It would make sense to drop the Qt5 build in favor of a Qt6 one. Regards, Sébastien
Bug#1041076: dolphin-emu FTBFS with imgui 1.89.6
Upstream is dealing with this here :
https://github.com/dolphin-emu/dolphin/pull/12065
Please find a minimal patch in attachement.
On Fri, 14 Jul 2023 20:09:01 +0300 Adrian Bunk wrote:
> Source: dolphin-emu
> Version: 5.0-19368+dfsg-2
> Severity: serious
> Tags: ftbfs
>
>
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dolphin-emu.html
>
> ...
> In file included from /build/1st/dolphin-emu-5.0-
19368+dfsg/Externals/implot/implot/implot_internal.h:39,
> from /build/1st/dolphin-emu-5.0-
19368+dfsg/Externals/implot/implot/implot_items.cpp:26:
> /usr/include/imgui/imgui_internal.h:101:2: error: #error Please
'#define IMGUI_DEFINE_MATH_OPERATORS' _BEFORE_ including imgui.h!
> 101 | #error Please '#define IMGUI_DEFINE_MATH_OPERATORS' _BEFORE_
including imgui.h!
> | ^
> In file included from /build/1st/dolphin-emu-5.0-
19368+dfsg/Externals/implot/implot/implot_internal.h:39,
> from /build/1st/dolphin-emu-5.0-
19368+dfsg/Externals/implot/implot/implot.cpp:126:
> /usr/include/imgui/imgui_internal.h:101:2: error: #error Please
'#define IMGUI_DEFINE_MATH_OPERATORS' _BEFORE_ including imgui.h!
> 101 | #error Please '#define IMGUI_DEFINE_MATH_OPERATORS' _BEFORE_
including imgui.h!
> | ^
> ...
>
>
--- a/Externals/implot/implot/implot.cpp
+++ b/Externals/implot/implot/implot.cpp
@@ -122,6 +122,7 @@
*/
+#define IMGUI_DEFINE_MATH_OPERATORS
#include "implot.h"
#include "implot_internal.h"
--- a/Externals/implot/implot/implot_internal.h
+++ b/Externals/implot/implot/implot_internal.h
@@ -31,10 +31,6 @@
#pragma once
-#ifndef IMGUI_DEFINE_MATH_OPERATORS
-#define IMGUI_DEFINE_MATH_OPERATORS
-#endif
-
#include
#include "imgui_internal.h"
--- a/Externals/implot/implot/implot_items.cpp
+++ b/Externals/implot/implot/implot_items.cpp
@@ -22,6 +22,7 @@
// ImPlot v0.14
+#define IMGUI_DEFINE_MATH_OPERATORS
#include "implot.h"
#include "implot_internal.h"
--- a/Source/Core/VideoCommon/OnScreenUI.cpp
+++ b/Source/Core/VideoCommon/OnScreenUI.cpp
@@ -356,35 +356,37 @@
}
void OnScreenUI::SetKeyMap(const DolphinKeyMap& key_map)
{
- // Right now this is a 1:1 mapping. But might not be true later
static constexpr DolphinKeyMap dolphin_to_imgui_map = {
ImGuiKey_Tab, ImGuiKey_LeftArrow, ImGuiKey_RightArrow, ImGuiKey_UpArrow,
ImGuiKey_DownArrow, ImGuiKey_PageUp,ImGuiKey_PageDown, ImGuiKey_Home,
ImGuiKey_End, ImGuiKey_Insert,ImGuiKey_Delete, ImGuiKey_Backspace,
- ImGuiKey_Space, ImGuiKey_Enter, ImGuiKey_Escape, ImGuiKey_KeyPadEnter,
+ ImGuiKey_Space, ImGuiKey_Enter, ImGuiKey_Escape, ImGuiKey_KeypadEnter,
ImGuiKey_A, ImGuiKey_C, ImGuiKey_V, ImGuiKey_X,
ImGuiKey_Y, ImGuiKey_Z,
};
- static_assert(dolphin_to_imgui_map.size() == ImGuiKey_COUNT); // Fail if ImGui adds keys
auto lock = GetImGuiLock();
if (!ImGui::GetCurrentContext())
return;
+ m_dolphin_to_imgui_map.clear();
for (int dolphin_key = 0; dolphin_key <= static_cast(DolphinKey::Z); dolphin_key++)
{
-int imgui_key = dolphin_to_imgui_map[DolphinKey(dolphin_key)];
+const int imgui_key = dolphin_to_imgui_map[DolphinKey(dolphin_key)];
if (imgui_key >= 0)
- ImGui::GetIO().KeyMap[imgui_key] = (key_map[DolphinKey(dolphin_key)] & 0x1FF);
+{
+ const int mapped_key = key_map[DolphinKey(dolphin_key)];
+ m_dolphin_to_imgui_map[mapped_key & 0x1FF] = imgui_key;
+}
}
}
void OnScreenUI::SetKey(u32 key, bool is_down, const char* chars)
{
auto lock = GetImGuiLock();
- if (key < std::size(ImGui::GetIO().KeysDown))
-ImGui::GetIO().KeysDown[key] = is_down;
+ if (auto iter = m_dolphin_to_imgui_map.find(key); iter != m_dolphin_to_imgui_map.end())
+ImGui::GetIO().AddKeyEvent((ImGuiKey)iter->second, is_down);
if (chars)
ImGui::GetIO().AddInputCharactersUTF8(chars);
--- a/Source/Core/VideoCommon/OnScreenUI.h
+++ b/Source/Core/VideoCommon/OnScreenUI.h
@@ -3,6 +3,7 @@
#pragma once
+#include
#include
#include
#include
@@ -65,6 +66,7 @@
std::unique_ptr m_imgui_vertex_format;
std::vector> m_imgui_textures;
std::unique_ptr m_imgui_pipeline;
+ std::map m_dolphin_to_imgui_map;
std::mutex m_imgui_mutex;
u64 m_imgui_last_frame_time = 0;
Bug#1042430: chatty warnings in logs when browsing sftp:// uri in nautilus
Package: gvfs-backends Version: 1.50.4-3 For some times now, i'm seeing too much warnings in the journal when browsing sftp:// uri in nautilus : gvfsd-sftp[145982]: GFileInfo created without standard::is-symlink gvfsd-sftp[145982]: file ../../../gio/gfileinfo.c: line 1631 (g_file_info_get_is_symlink): should not be reached gvfsd-sftp[145982]: GFileInfo created without standard::is-symlink gvfsd-sftp[145982]: file ../../../gio/gfileinfo.c: line 1631 (g_file_info_get_is_symlink): should not be reached [...] I already reported the problem and a fix upstream https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/184 but if you could backport this fix to the debian packages that would be great :-) Regards, Sébastien
Bug#1037098: RFS: serious-engine/0~git20230515+dfsg-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "serious-engine": * Package name : serious-engine Version : 0~git20230515+dfsg-1 Upstream contact : https://github.com/ptitSeb/Serious-Engine/issues * URL : https://www.croteam.com/serious-sam-source-code-released/ * License : GPL-2 * Vcs : https://salsa.debian.org/twolife/serious-engine Section : contrib/games The source builds the following binary packages: serious-sam-tfe - Serious Sam - The First Encounter serious-sam-tse - Serious Sam - The Second Encounter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/serious-engine/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/s/serious-engine/serious-engine_0~git20230515+dfsg-1.dsc Changes for the initial release: serious-engine (0~git20230515+dfsg-1) unstable; urgency=low . * Initial release. Closes: #1034630 This package alone isn't of any use; it only contains the game engine, an engine that has no Free data and therefore is in contrib. You will need a copy of the original game for this package to be useful. Please use/build the git version of game-data-packager https://salsa.debian.org/games-team/game-data-packager to build a .deb of proprietary data (gog or steam) to unleash the full potential of this code. Best Regards, Sébastien
Bug#1034630: ITP: serious-engine -- game engine developed for the classic Serious Sam games
Package: wnpp Severity: wishlist Owner: Sébastien Noel X-Debbugs-Cc: debian-de...@lists.debian.org, sebast...@twolife.be * Package name: serious-engine Version : 0~git20230405 * URL : https://github.com/ptitSeb/Serious-Engine/ * License : GPLv2 Programming Lang: C++ Description : first-person shooter game engine The serious-engine serve as the base for two games developed by Croteam and originally published in 2001 & 2002 : The series follows the adventures of protagonist Sam "Serious" Stone and his fight against the forces of the notorious extraterrestrial overlord Mental, who seeks to destroy humanity. This package alone isn't of any use; it only contains the game engine, you will need a copy of the original game for this package to be useful. This can be purchased from GOG.
Bug#986740: forked-daapd : please package new upstream release
Ok it's been 2 years now, without even an ACK of some sort If there isn't any interest on your part in this package, i'm more than willing to adopt it.
Bug#1032282: pyotherside : please build a Qt6 flavor of the package
Package: src:pyotherside
Severity: wishlist
Dear Maintainer,
Currently you are building only a Qt 5 plugins,
but upstream source code is also compatible with Qt6.
Could you please build the Qml6 plugin ?
I already did it locally, please find the debdiff in attachment.
Best regards,
Sébastien
diff -Nru pyotherside-1.6.0/debian/control pyotherside-1.6.0/debian/control
--- pyotherside-1.6.0/debian/control
+++ pyotherside-1.6.0/debian/control
@@ -7,25 +7,23 @@
python3-dev,
python3-sphinx,
qt5-qmake,
+ qmake6,
qtbase5-dev,
+ qt6-base-dev,
qtdeclarative5-dev,
+ qt6-declarative-dev,
xauth,
xvfb,
libqt5svg5-dev,
- libqt5opengl5-dev
+ libqt6svg6-dev,
+ libqt5opengl5-dev,
+ libqt6opengl6-dev,
Standards-Version: 4.6.1
Rules-Requires-Root: no
Vcs-Git: https://salsa.debian.org/python-team/packages/pyotherside.git
Vcs-Browser: https://salsa.debian.org/python-team/packages/pyotherside
Homepage: https://thp.io/2011/pyotherside/
-Package: pyotherside
-Depends: qml-module-io-thp-pyotherside, ${misc:Depends}
-Description: transitional dummy package
- This is a transitional dummy package. It can safely be removed.
-Architecture: all
-Section: oldlibs
-
Package: qml-module-io-thp-pyotherside
Multi-Arch: same
Architecture: any
@@ -46,13 +44,29 @@
objects to Python objects and vice versa, with focus on asynchronous events
and continuation-passing style function calls.
.
- While legacy versions of PyOtherSide worked with Qt 4.x and Python 2.x, its
- focus now lies on Python 3.x and Qt 5. Python 3 has been out for several
- years, and offers some nice language features and clean-ups, while Qt 5
- supports most mobile platforms well, and has an improved QML engine and a
- faster renderer (Qt Scene Graph) compared to Qt 4.
+ This package provides the QML 5 plugin.
+
+Package: qml6-module-io-thp-pyotherside
+Multi-Arch: same
+Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
+Depends: python3:any, ${misc:Depends}, ${shlibs:Depends}
+Description: asynchronous Python 3 Bindings for Qt 6 (QML plugin)
+ A Qt 6 QML Plugin that provides access to a Python 3 interpreter from QML.
+ .
+ PyOtherSide is a Qt QML Plugin that provides access to a Python 3
+ interpreter from QML. It was designed with mobile devices in mind, where
+ high-framerate touch interfaces are common, and where the user usually
+ interfaces only with one application at a time via a touchscreen. As such, it
+ is important to never block the UI thread, so that the user can always
+ continue to use the interface, even when the backend is processing,
+ downloading or calculating something in the background.
+ .
+ At its core, PyOtherSide is basically a simple layer that converts Qt (QML)
+ objects to Python objects and vice versa, with focus on asynchronous events
+ and continuation-passing style function calls.
.
- This package provides the QML plugin.
+ This package provides the QML 6 plugin.
Package: pyotherside-doc
Section: doc
@@ -60,10 +74,10 @@
Architecture: all
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${sphinxdoc:Depends}
-Description: asynchronous Python 3 Bindings for Qt 5 (documentation)
- A Qt 5 QML Plugin that provides access to a Python 3 interpreter from QML.
+Description: asynchronous Python 3 Bindings for Qt (documentation)
+ A Qt QML Plugin that provides access to a Python 3 interpreter from QML.
.
- PyOtherSide is a Qt 5 QML Plugin that provides access to a Python 3
+ PyOtherSide is a Qt QML Plugin that provides access to a Python 3
interpreter from QML. It was designed with mobile devices in mind, where
high-framerate touch interfaces are common, and where the user usually
interfaces only with one application at a time via a touchscreen. As such, it
@@ -75,12 +89,6 @@
objects to Python objects and vice versa, with focus on asynchronous events
and continuation-passing style function calls.
.
- While legacy versions of PyOtherSide worked with Qt 4.x and Python 2.x, its
- focus now lies on Python 3.x and Qt 5. Python 3 has been out for several
- years, and offers some nice language features and clean-ups, while Qt 5
- supports most mobile platforms well, and has an improved QML engine and a
- faster renderer (Qt Scene Graph) compared to Qt 4.
- .
This package provides the HTML documentation as well as the set of examples.
Package: pyotherside-tests
@@ -92,10 +100,10 @@
python3:any,
${misc:Depends},
${shlibs:Depends}
-Description: Asynchronous Python 3 Bindings for Qt 5 (tests)
- A Qt 5 QML Plugin that provides access to a Python 3 interpreter from QML.
+Description: Asynchronous Python 3 Bindings for Qt (tests)
+ A Qt QML Plugin that provides access to a Python 3 interpreter from QML.
.
- PyOtherSide is a Qt 5 QML Plugin that provides
Bug#982147: Test case for libmgba-dev
Hi ! Le 2021-09-04 21:17, Ryan Tandy a écrit : Hello, I'm working on the libmgba-dev package. Can either of you share a link to a project or test case that I can use to test it? or would either of you be willing to test the package if I push the changes (or a repo of built packages) somewhere? Sorry, no easy test-case to share with you, but I can test your WIP packages against a local modified Dolphin build. br, Sébastien
Bug#982147: mgba: Please provide a libmgba-dev package
Hi ! On Sat, 6 Feb 2021 13:41:04 -0800 Ryan Tandy wrote: What is the software that would like to use this? Is it (or would it eventually be) in Debian? New version of Dolphin, the Gamecube and Wii emulator (src:dolphin-emu), have now the possibility to link to libmgba. You can read more info about that here: https://dolphin-emu.org/blog/2021/07/21/integrated-gba/ (it requires a more recent version of mgba, but that's another topic) I know that unfortunately the official dolphin debian package is stuck to a very old version, but I hope that this will change in the near future (see #986739). It would be very cool if we can ship a libmgba-enabled dolphin package in Debian, so I hope that a libmgba-dev package is not completely out-of-the-question now that bullseye is released :-) Best regards, Sébastien
Bug#754809: Debian bug-tracking system still generating bouncing emails that violate DMARC
Same observation here: DMARC aggregate reports notifies me that emails sends to the BTS are not delivered to the final recipient. I should not be surprised anymore if bugreports are left un-answered, maintainers are simply not getting notification... Since the last comment of this bug, 4 months have passed and no reaction. I suspect that nobody recieved the last email, and my guts tell me that i'm writing to /dev/null rigth now :( Without a working BTS, i'm wondering : Is the project still interested by users' feedback ?
Bug#992871: darkplaces: Segfault when using custom texturepack
Package: darkplaces Severity: normal Dear Maintainer, The current darkplaces debian packages segfault when using "Rygel's ultra pack". PNG_LoadImage: warning: iCCP: known incorrect sRGB profile PNG_LoadImage: warning: Interlace handling should be turned on when using png_read_image [...] PNG_LoadImage: warning: Interlace handling should be turned on when using png_read_image PNG_fReadData: overrun by 8 bytes PNG_LoadImage: error: [00][00][00][00]: invalid chunk type libpng error: [00][00][00][00]: invalid chunk type Segmentation fault Since this pack is linked from the original upstream project, at https://icculus.org/twilight/darkplaces/download.html under "Quake art enhancement projects", I suspected this was a tested/validated configuration. When using a recent upstream snapshot compiled by myself, everything worked fine. So I started digging... The problem disapers once I rebuild the debian package & replace "DP_LINK_PNG=shared" by "DP_LINK_PNG=dlopen" in d/rules. I wish I could more precisely spot the problem but my knowledge about dlopen and all its mysteries ends pretty quickly... Best Regards, Sébastien
Bug#990121: osspd: revert debhelper compat bump to get #986662 fixed in bullseye
Hi Simon, Hi Ralf, Le lundi 21 juin 2021 à 20:11 +0100, Simon McVittie a écrit : > On Mon, 21 Jun 2021 at 12:43:43 +0200, Ralf Jung wrote: > > [...] > > Those changes were suggested for inclusion by Sébastien (CC'ed). I > > don't know more about them than what it says in the patch files. > > They both come from upstream osspd git. > > I'll wait to see what Sébastien says about these, then. Well, sorry to disappoint you both, but i really have nothing exciting to say about those :/ GIT-fix-adsp_se.patch seems like it could fix something, but honestly, even after 20 years of linux gaming (and countless hours of figth with oss3, alsa, pulseaudio, oss4), i didn't remenber having to deal with /dev/adsp, so "no", i can't say if it solve a real bug or not :/ (if /dev/adsp is really "alternative DSP/secoundary soundcard", i really doubt it will be of use in UT99 or another game of that era) GIT-fix-compiler-warnings.patch is more or less a no-op Those 2 patches seemed like a good fit for the (very) slow moving target the osspd package is, but i agree the timing was wrong :/ Best regards, Sébastien
Bug#986740: forked-daapd : please package new upstream release
Package: src:forked-daapd Severity: wishlist Dear Maintainer, forked-daapd has a new name & had a few releases since the last time this package was updated. https://github.com/ejurgensen/forked-daapd now redirect to https://github.com/owntone/owntone-server and version 27.4 was released less than a month ago Thanks for taking care of this package. Best regards, Sébastien
Bug#986739: is it possible to package new upstream "snapshot" ?
Package: src:dolphin-emu Severity: wishlist Dear Maintainer, The current dolphin-emu packages lacks almost 5 years of upstream improvements. I know that technically there isn't any new upstream release, but my feeling is that this is getting ridiculous. The current package has lots of bugs regarding the usage of a real wiimote, lots of games are unplayable, the GUI is antique (upstream switched to QT5 3 years ago), etc... Current documentation and user expectations are way out of line with the state of the official debian package stuck at the 5.0 release. If you agree with me that an update is welcome, I'm not coming empty handed, I did my homework, I can share my current progress, but I struggled on 2 points: * some embedded libs (FreeSurround, minizip, ...) are more up2date in the tarball than the debian packaged version, so I used the bundled one * updating the d/copyright file is a real pain This is clearly not "release material" but it's a start: https://twolife.be/debian/pool/main/d/dolphin-emu/ Thanks for reading up to this point. Best Regards, Sébastien
Bug#986662: ossp-padsp not working with recent Pulseaudio
Package: osspd-pulseaudio
Severity: important
Dear Maintainer,
The current osspd packages isn't working with current pulseaudio and it
hasn't
for more than a year. I didn't file a bug back then, but I can confirm
that
at the time it was a pulseaudio update that broke osspd.
Downgrading to an earlier version fixed the problem.
Here is what the osspd logs says:
ossp-padsp[] WARN: failed to subscribe to context events (Bad state)
ossp-padsp[] ERR: failed to connect context, state=5 (Bad state)
This bug has also been reported on launchpad for Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/osspd/+bug/1857810
Almost 18 months later, I did found (by pure luck) that the ArchLinux
package
has a fix for this problem.
Please find a debdiff in attachment so that you can upload the fix in
Debian.
Best Regards,
Sébastien
diff -Nru osspd-1.3.2/debian/changelog osspd-1.3.2/debian/changelog
--- osspd-1.3.2/debian/changelog 2019-01-25 15:36:20.0 +0100
+++ osspd-1.3.2/debian/changelog 2021-04-08 09:01:51.0 +0200
@@ -1,3 +1,13 @@
+osspd (1.3.2-12) UNRELEASED; urgency=low
+
+ * cherrypick 2 commits from upstream GIT:
++ d/p/GIT-fix-adsp_se.patch
++ d/p/GIT-fix-compiler-warnings.patch
+ * Add workaround for pulseaudio >= 13
+d/p/Hack-to-work-with-modern-PulseAudio.patch
+
+ -- Sébastien Noel Thu, 08 Apr 2021 09:01:51 +0200
+
osspd (1.3.2-11) unstable; urgency=medium
* Update Standards-Version to 4.3.0. No changes needed.
diff -Nru osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch
--- osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch 1970-01-01 01:00:00.0 +0100
+++ osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch 2021-04-08 09:01:51.0 +0200
@@ -0,0 +1,24 @@
+From 4c6161d951daa98f6463904f76b3fa2ce7216194 Mon Sep 17 00:00:00 2001
+From: Tejun Heo
+Date: Mon, 21 Feb 2011 11:54:06 +0100
+Subject: [PATCH] adsp_se was incorrectly created with dsp_ops. Create it with
+ adsp_ops.
+
+Reported-by: Aaron
+---
+ osspd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/osspd.c b/osspd.c
+index 37c9b35..df1cfc4 100644
+--- a/osspd.c
b/osspd.c
+@@ -2253,7 +2253,7 @@ int main(int argc, char **argv)
+ param.mixer_major, param.mixer_minor,
+ args.argc, args.argv);
+ if (strlen(param.adsp_name))
+- adsp_se = setup_ossp_cuse(_ops, param.adsp_name,
++ adsp_se = setup_ossp_cuse(_ops, param.adsp_name,
+ param.adsp_major, param.adsp_minor,
+ args.argc, args.argv);
+
diff -Nru osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch
--- osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch 1970-01-01 01:00:00.0 +0100
+++ osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch 2021-04-08 08:58:42.0 +0200
@@ -0,0 +1,251 @@
+From 37eb730a452f0ded2ed1c174feb438e3df041581 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi
+Date: Fri, 11 Nov 2011 14:19:32 +0100
+Subject: [PATCH] fix compiler warnings
+
+---
+ ossp-padsp.c | 3 ---
+ osspd.c | 75 ++--
+ 2 files changed, 44 insertions(+), 34 deletions(-)
+
+diff --git a/ossp-padsp.c b/ossp-padsp.c
+index 1871f5b..3143960 100644
+--- a/ossp-padsp.c
b/ossp-padsp.c
+@@ -972,16 +972,13 @@ static void do_mmap_read(size_t bytes)
+
+ static void stream_rw_callback(pa_stream *s, size_t length, void *userdata)
+ {
+- int dir;
+ size_t size;
+
+ if (s == stream[PLAY]) {
+- dir = PLAY;
+ size = pa_stream_writable_size(s);
+ if (mmap_map[PLAY])
+ do_mmap_write(size);
+ } else if (s == stream[REC]) {
+- dir = REC;
+ size = pa_stream_readable_size(s);
+ if (mmap_map[REC])
+ do_mmap_read(size);
+diff --git a/osspd.c b/osspd.c
+index df1cfc4..4be1ad5 100644
+--- a/osspd.c
b/osspd.c
+@@ -469,15 +469,6 @@ static int ioctl_prep_uarg(fuse_req_t req, void *in, size_t in_sz, void *out,
+ return; \
+ } while (0)
+
+-#define IOCTL_RETURN(result, outp) do { \
+- if ((outp) != NULL) \
+- fuse_reply_ioctl(req, result, (outp), sizeof(*(outp))); \
+- else\
+- fuse_reply_ioctl(req, result, NULL, 0); \
+- return;\
+-} while (0)
+-
+-
+ /***
+ * Mixer implementation
+ */
+@@ -709,7 +700,8 @@ static void mixer_simple_ioctl(fuse_req_t req, struct ossp_mixer *mixer,
+ strncpy(info.id, id, sizeof(info.id) - 1);
+ strncpy(info.name, name, sizeof(info.name) - 1);
+ info.modify_counter = mixer->modify_counter;
+- IOCTL_RETURN(0, );
++ fuse_reply_ioctl(req, 0, , sizeof(info));
++ break;
+ }
+
+ case SOUND_OLD_MIXER_INFO: {
+@@ -718,7 +710,8 @@ static void mixer_simple_ioctl(fuse_req_t req, struct ossp_mixer *mixer,
+ PREP_UARG(NULL, );
+ strncpy(info.id, id, sizeof(info.id) - 1);
+ strncpy(info.name, name, sizeof(info.name) - 1);
+- IOCTL_RETURN(0, );
++ fuse_reply_ioctl(req,
Bug#972973: Please re-enable SECO HDMI CEC driver (CONFIG_VIDEO_SECO_CEC)
Package: src:linux Severity: wishlist Dear Maintainer, Could you please re-enable the option CONFIG_VIDEO_SECO_CEC ? I already did requested this via bug #951543, it worked for a time, but since linux-5.8 it seems you disabled it again :'( # grep -i seco /boot/config-5.7.0-0.bpo.2-amd64 CONFIG_VIDEO_SECO_CEC=m $ grep -i seco /boot/config-5.8.0-0.bpo.2-amd64 # CONFIG_CEC_SECO is not set Could you explain why you did remove this module ? Best regards, Sébastien
Bug#951543: Please enable SECO HDMI CEC driver
Package: src:linux Severity: wis hlist Tags: patch Dear Maintainer, Could you please enable CONFIG_VIDEO_SECO_CEC ? That device is found on x86 board from UDOO, it would be very cool to not have to rebuild the kernel by hand :-) Thanks. Sébastien --- a/config-5.4.13 +++ b/config-5.4.13 @@ -4797,6 +4797,7 @@ # CONFIG_REGULATOR_TPS65132 is not set # CONFIG_REGULATOR_TPS6524X is not set CONFIG_CEC_CORE=y +CONFIG_CEC_NOTIFIER=y CONFIG_RC_CORE=m CONFIG_RC_MAP=m CONFIG_LIRC=y @@ -5122,7 +5123,9 @@ # CONFIG_VIDEO_VIM2M is not set # CONFIG_VIDEO_VICODEC is not set # CONFIG_DVB_PLATFORM_DRIVERS is not set -# CONFIG_CEC_PLATFORM_DRIVERS is not set +CONFIG_CEC_PLATFORM_DRIVERS=y +CONFIG_VIDEO_SECO_CEC=m +CONFIG_VIDEO_SECO_RC=y # CONFIG_SDR_PLATFORM_DRIVERS is not set #
Bug#900610: easy-rsa: make-cadir is not included in package
Hi, Just for your information: in addition to not being included in the .deb package, the make-cadir script in the source package has a nasty typo: on line 27, 'x590' should be 'x509' best regards, Sébastien
Bug#723193: final 0.9 release still not in unstable
reopen 723193 thanks it's been months now that you are sorting things out in experimental, and we still don't have a decent package in testing/unstable. (decent == not with an alpha version dated from a year old) so no, this bug should not be closed: it is not fixed On Thu, 02 Jan 2014 18:25:53 +0100 Daniel Baumann daniel.baum...@progress-technologies.net wrote: close 723193 thanks please stop re-opening closed bugs uselessly. as said in the bug report, there'll be an upload to unstable once the disruptive changes have been sorted out in experimental. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723193: final 0.9 release still not in unstable
Hi, Same request as Laurent, could you upload a recent package (like the final 0.9 release) with the lxc-debian template shipped by upstream please ? Thanks Sébastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693659: vmix floating-point mode does not use proper API on Linux
Hi, On Sat, 24 Nov 2012 04:36:43 -0500 Michael Gilbert mgilb...@debian.org wrote: Hi, I've prepared an nmu based on the patch. See attached. Let me know if you want to upload it, or I'll do so in a couple days. I will not have time to properly test that patch right now. If you use it it doesn't break anything for you, feel free to upload your NMU. Best wishes, Mike Best regards, Sébastien signature.asc Description: PGP signature
Bug#640499: libxvmc: please add multiarch support
On Wed, 19 Sep 2012 20:20:40 +0200 Julien Cristau jcris...@debian.org wrote: On Wed, Sep 19, 2012 at 12:56:23 +0200, Ralf Jung wrote: Why that? This would effectively mean broken OpenGL for i386 apps on systems using the proprietary NVidia driver. The patch from the original report is simple and working on several people's systems. The dpkg issues are unrelated and apply to other packages as well. At least an upload to Sid with that patch applied would be appropriate IMHO, then the release team can decide whether they want it in Wheezy or not. Or is there a problem with the patch itself, preventing the bug from being fixed in Sid? Because if there's two things in the world I don't care about it's wine and the nvidia driver. So I won't spend any of my free time trying to unbreak them when I've got more important things to do. do you care about release goals ? you know that multiarch is one of them, right ? do you care about the social contract ? you know, that little sentence Our priorities are our users... you don't care about wine the nvidia driver ? Fine. Like it or not, but it's not about wine or the nvidia drivers. This bug is about multiarch and we -the users- are just asking for that. And it doesn't require you to work on it, patches have already been written and posted in this bug report Cheers, Julien Regards, Sebastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
