Bug#1058712: ITP: sddm-conf -- Graphical editor for SDDM
I have prepared the packaging for Debian, porting it from the Ubuntu packaging created originally by Simon Quigley which I further enhanced. The Git repository is at https://salsa.debian.org/ArrayBolt3/sddm-conf. CC'ing Simon for review. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub:https://github.com/ArrayBolt3
Bug#1061277: abinit: FTBFS with Python 3.12
Source: abinit
Version: 9.10.4-2
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: arraybo...@ubuntu.com
When building the abinit package on a system with Python 3.12 installed,
the build fails with a "ModuleNotFoundError: No module named 'imp'" in
fkiss/project.py. This file is used by abisrc.py, which is used as a
critical part of the build configuration process, thus when this script
fails, it takes down the whole build.
This bug is being tracked upstream at
https://github.com/abinit/abinit/issues/69.
Steps to reproduce:
1. Configure your builder to enable `experimental` and pin
python3-defaults to be installed from it. I'm doing this with a script
as follows:
```
#!/bin/bash
echo "deb https://deb.debian.org/debian experimental main" >>
/etc/apt/sources.list;
echo "deb-src https://deb.debian.org/debian experimental main" >>
/etc/apt/sources.list;
echo "Package: src:python3-defaults" > /etc/apt/preferences.d/99proposed
echo "Pin: release a=experimental" >> /etc/apt/preferences.d/99proposed
echo "Pin-Priority: 950" >> /etc/apt/preferences.d/99proposed
```
This is then called in my .sbuildrc with the following config:
```
$external_commands = {
"chroot-setup-commands" => [
['/repo/enableProposed.sh'],
],
};
```
2. Attempt to build abinit from source with this builder. The build will
fail and display failure output similar to the output in the upstream
bug report. You should be able to find the abisrc.stderr file inside the
build directory within your builder (find it with `find | grep stderr`)
and see that it has output similar to the output shown in the first
comment of the upstream bug report.
(My system information has Ubuntu information on it because I am
reporting the bug from an Ubuntu system, however the FTBFS occurs within
a Debian Sid schroot being used via sbuild.)
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-14-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1058713: ITP: picom-conf -- Configuration editor for Picom
The packaging has been finished and a Salsa repo containing the upstream code and packaging can now be found at https://salsa.debian.org/ArrayBolt3/picom-conf. Ready for review. Copying Simon in on this since I'm hoping he'll review it for me. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1057750: ciso: Please update to ciso 1.0.2
Sorry for the late reply. I'd be happy to co-maintain ciso. Thanks! The patch was taken from upstream, so I'm not sure why you're getting failures. I'll take a closer look hopefully in the near future. Perhaps the ciso packaging you have on your system has changes that aren't in the archive already? Thanks for your help! On 12/11/23 06:53, Gürkan Myczko wrote: Hi Aaron On 08.12.2023 00:36, Aaron Rainbolt wrote: Debdiff prepared and attached. Please review this whenever you get a chance and tell me if there's anything I can do better. Thanks! Thank you for the patch. Would it be possible to upstream this? https://github.com/jamie/ciso If upstream doesn't accept your patches, would you be willing to fork and continue? debian/changelog, your entries look fine, would you like to be co-maintainer or not? I didn't take a look at why it failed with ciso.c and ciso.h yet, but here's the output: $ patch -p1 < ../update.patch patching file README.markdown patching file ciso.c Hunk #1 FAILED at 22. Hunk #2 succeeded at 32 (offset 1 line). Hunk #3 succeeded at 44 (offset 1 line). Hunk #4 succeeded at 81 (offset 1 line). Hunk #5 succeeded at 118 (offset 1 line). Hunk #6 succeeded at 139 (offset 1 line). Hunk #7 succeeded at 238 (offset 1 line). Hunk #8 succeeded at 251 (offset 1 line). Hunk #9 succeeded at 280 (offset 1 line). Hunk #10 succeeded at 307 (offset 1 line). Hunk #11 succeeded at 402 (offset 1 line). 1 out of 11 hunks FAILED -- saving rejects to file ciso.c.rej patching file ciso.h Hunk #1 FAILED at 19. 1 out of 1 hunk FAILED -- saving rejects to file ciso.h.rej patching file debian/changelog patching file debian/control patching file debian/copyright patching file debian/patches/01_mem_alloc_failure_amd64.patch patching file debian/patches/series patching file debian/patches/usage-syntax patching file debian/upstream/metadata patching file debian/watch -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1058713: ITP: picom-conf -- Configuration editor for Picom
Package: wnpp Severity: wishlist Owner: Aaron Rainbolt X-Debbugs-Cc: debian-de...@lists.debian.org, arraybo...@ubuntu.com * Package name: picom-conf Version : 0.17.0 Upstream Contact: redtide * URL : https://github.com/qtilities/picom-conf * License : Mixed (LGPL-2.1, Expat, CC0-1.0, and some LGPL-3+ icons) Programming Lang: C++ Description : Configuration editor for Picom picom-conf is a configuration tool for the Picom X compositor. It allows modifying Picom's settings using a graphical user interface. It is the successor to the now-abandoned compton-conf. It is written in Qt, and would be handy for users of Qt-based desktop environments that use Picom. The Lubuntu team has already packaged picom-conf for our flavor of Ubuntu. We have the ability and the willingness to keep it maintained in Debian.
Bug#1058712: ITP: sddm-conf -- Graphical editor for SDDM
Package: wnpp Severity: wishlist Owner: Aaron Rainbolt X-Debbugs-Cc: debian-de...@lists.debian.org, arraybo...@ubuntu.com * Package name: sddm-conf Version : 0.1.0 Upstream Contact: redtide * URL : https://github.com/qtilities/sddm-conf * License : MIT (with some LGPL-3+ icons) Programming Lang: C++ Description : Graphical editor for SDDM sddm-conf provides a way to edit various SDDM-related settings using a graphical user interface. It is part of the Qtilities suite, and is particularly handy for desktop environments that are Qt-based but not KDE-based or only minimally KDE-based (such as LXQt). This program is the successor to sddm-config-editor, which had an RFP bug filed for it here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868562 sddm-config-editor is now abandoned. The Lubuntu team is already shipping sddm-conf in our flavor of Ubuntu. We have both the ability and the willingness to keep it maintained in Debian. Qtilitools is a dependency of sddm-conf, and therefore this software will require Qtilitools to be uploaded before it is usable. The ITP bug for Qtilitools is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058651.
Bug#1058651: ITP: qtilitools -- Scripts/commands used in the Qtilities organization.
A Debian package for qtilitools is now available at https://salsa.debian.org/ArrayBolt3/qtilitools. It is based on the corresponding Ubuntu package put together by Simon Quigley, whom I have copied on this email to request sponsorship. The package builds Lintian-clean with sbuild. If someone (most likely Simon) could review and sponsor it, that would be great. Thanks! -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1058651: ITP: qtilitools -- Scripts/commands used in the Qtilities organization.
Package: wnpp Severity: wishlist Owner: Aaron Rainbolt X-Debbugs-Cc: debian-de...@lists.debian.org, arraybo...@ubuntu.com * Package name: qtilitools Version : 0.1.2 Upstream Contact: redtide * URL : https://github.com/qtilities/qtilitools * License : BSD-3-Clause Programming Lang: CMake + Shell + Perl Description : Scripts/commands used in the Qtilities organization. Qtilitools is a collection of scripts and commands used to help build applications in the Qtilities suite. The Qtilities suite of applications include a number of helpful programs such as picom-conf (a configuration tool for the Picom compositor), sddm-conf (used for configuring the SDDM display manager), and a couple other potentially handy tools like a screen magnifier, color picker, and screenshot capturing utility. As the name would suggest, the Qtilities suite is heavily Qt-based, and fills a gap long left in the world of Qt-based desktop environments that aren't also KDE-based (such as LXQt). This package must be present in the archive before any future Qtilities can be uploaded. As I intend on submitting packaging for sddm-conf and picom-conf in the near future, I am preparing qtilitools first. The Lubuntu team already is shipping some of the Qtilities in our flavor of Ubuntu, to help supplement LXQt. We have the ability and willingness to keep these tools maintained in Debian.
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 12/10/23 12:08, Bas Wijnen wrote: On Sun, Dec 03, 2023 at 02:18:38AM -0600, Aaron Rainbolt wrote: [Catch 2] While it is definitely possible to port the openMSX tests to use catch2 v3, we will be departing from what upstream supports, and that seems like it could lead to way more work than necessary (for instance, what if the next major release of openMSX still uses catch2 v2 and uses it in a way that's incompatible with catch2 v3? Then we have to maintain that delta from upstream ourselves, possibly for an extended period of time). You are misunderstanding me. First of all, I was expecting the changes to be minor. So I was thinking we can write a patch and let upstream use it. They are very responsive, so I would expect them to include our patch immediately. However, if it is a lot of work, it might be better to just file a bug report upstream. I would expect them to respond to that as well, by doing it themselves. Although it might take some time. So because we are in a bit of a hurry with openMSX dropping from testing, I think the approach for now is to use the bundled catch2-v2, and either port it for them, or let them know it needs to be ported. One possible solution might be for Debian to ship multiple major versions of catch2. I don't know enough about catch2 to know if that is a good idea. It might be, but it's certainly out of the scope of this problem. Maybe this is something we can bring up to whoever maintains catch2 in Debian. Yes, that sounds like a good idea. They will probably have an intelligent opinion about it. I'm not so sure it's a Lintian bug since HTML files oftentimes *are* compiled from other source code. They are, but Lintian is now very forceful in saying that files like these are definitely compiled, which is just false. So if there is no better way to detect this, at the very least the certainty of the problem should be decreased (from error to warning, for example). It is quite common for hand-written text files (including html files) to contain long lines and it is not reasonable for all those files to either be required to be line-wrapped, nor for all those packages to contain overrides. I think that due to the urgency, I'll make a new package based on your work and upload it. We can figure out how to handle the remaining issues after that. Sounds good, and I'll see about a catch2 v3 port. (Part of the reason I was against that idea was because I actually tried to do it and it failed miserably. I didn't understand enough about how exactly the openMSX build system worked to do it "right" and the quick-and-dirty way of doing it was discouraged in the catch2 documentation.) I'll probably have to learn Perl before I can look into Lintian, but I've wanted to learn it before anyway, so may as well do so now. Thanks you for all your help with this! Thanks again, Bas -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1057883: signond: Some optional symbols are not marked as such in the symbols files
Package: signond Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch X-Debbugs-Cc: arraybo...@ubuntu.com Some symbols in the symbols files are optional, and vanish when the package is built on Ubuntu, resulting in an FTBFS. While not strictly necessary in Debian at the moment, it would be helpful for these symbols were marked optional. (There's also a couple of Lintian overrides that need syntax fixes.) In Ubuntu, the attached patch was applied to fix both of these issues. Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-9-generic (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) diff -Nru signond-8.61/debian/libsignon-extension1.symbols signond-8.61/debian/libsignon-extension1.symbols --- signond-8.61/debian/libsignon-extension1.symbols2022-03-11 20:45:00.0 + +++ signond-8.61/debian/libsignon-extension1.symbols2023-12-10 02:45:20.0 + @@ -55,16 +55,16 @@ _ZN6SignOn18AbstractKeyManagerD0Ev@Base 8.57+20150423 _ZN6SignOn18AbstractKeyManagerD1Ev@Base 8.57+20150423 _ZN6SignOn18AbstractKeyManagerD2Ev@Base 8.57+20150423 - _ZN6SignOn18ExtensionInterfaceD0Ev@Base 8.57+20150423 - _ZN6SignOn18ExtensionInterfaceD1Ev@Base 8.57+20150423 - _ZN6SignOn18ExtensionInterfaceD2Ev@Base 8.57+20150423 + (optional) _ZN6SignOn18ExtensionInterfaceD0Ev@Base 8.57+20150423 + (optional) _ZN6SignOn18ExtensionInterfaceD1Ev@Base 8.57+20150423 + (optional) _ZN6SignOn18ExtensionInterfaceD2Ev@Base 8.57+20150423 _ZN6SignOn18setFilePermissionsERK7QString6QFlagsIN11QFileDevice10PermissionEEb@Base 8.57+20150423 - _ZN6SignOn19ExtensionInterface2D0Ev@Base 8.57+20150423 - _ZN6SignOn19ExtensionInterface2D1Ev@Base 8.57+20150423 - _ZN6SignOn19ExtensionInterface2D2Ev@Base 8.57+20150423 - _ZN6SignOn19ExtensionInterface3D0Ev@Base 8.57+20150423 - _ZN6SignOn19ExtensionInterface3D1Ev@Base 8.57+20150423 - _ZN6SignOn19ExtensionInterface3D2Ev@Base 8.57+20150423 + (optional) _ZN6SignOn19ExtensionInterface2D0Ev@Base 8.57+20150423 + (optional) _ZN6SignOn19ExtensionInterface2D1Ev@Base 8.57+20150423 + (optional) _ZN6SignOn19ExtensionInterface2D2Ev@Base 8.57+20150423 + (optional) _ZN6SignOn19ExtensionInterface3D0Ev@Base 8.57+20150423 + (optional) _ZN6SignOn19ExtensionInterface3D1Ev@Base 8.57+20150423 + (optional) _ZN6SignOn19ExtensionInterface3D2Ev@Base 8.57+20150423 _ZN6SignOn21AbstractCryptoManager10initializeERK4QMapI7QString8QVariantE@Base 8.57+20150423 _ZN6SignOn21AbstractCryptoManager11qt_metacallEN11QMetaObject4CallEiPPv@Base 8.57+20150423 _ZN6SignOn21AbstractCryptoManager11qt_metacastEPKc@Base 8.57+20150423 diff -Nru signond-8.61/debian/libsignon-plugins-common1.symbols signond-8.61/debian/libsignon-plugins-common1.symbols --- signond-8.61/debian/libsignon-plugins-common1.symbols 2022-03-11 21:01:01.0 + +++ signond-8.61/debian/libsignon-plugins-common1.symbols 2023-12-10 02:45:20.0 + @@ -22,9 +22,9 @@ _ZN6SignOn13BlobIOHandler8sendDataERK4QMapI7QString8QVariantE@Base 8.57+20150423 _ZN6SignOn13BlobIOHandlerC1EP9QIODeviceS2_P7QObject@Base 8.57+20150423 _ZN6SignOn13BlobIOHandlerC2EP9QIODeviceS2_P7QObject@Base 8.57+20150423 - _ZN6SignOn13BlobIOHandlerD0Ev@Base 8.57+20150423 - _ZN6SignOn13BlobIOHandlerD1Ev@Base 8.57+20150423 - _ZN6SignOn13BlobIOHandlerD2Ev@Base 8.57+20150423 + (optional) _ZN6SignOn13BlobIOHandlerD0Ev@Base 8.57+20150423 + (optional) _ZN6SignOn13BlobIOHandlerD1Ev@Base 8.57+20150423 + (optional) _ZN6SignOn13BlobIOHandlerD2Ev@Base 8.57+20150423 (optional=templinst)_ZN7QVectorI10QByteArrayE6appendERKS0_@Base 8.57+20150423 (optional=templinst)_ZN7QVectorI10QByteArrayE7reallocEi6QFlagsIN10QArrayData16AllocationOptionEE@Base 8.60 (optional=templinst)_ZN8QMapNodeI7QString8QVariantE14destroySubTreeEv@Base 8.57+20150423 @@ -46,29 +46,29 @@ _ZN19AuthPluginInterface11qt_metacastEPKc@Base 8.57+20150423 _ZN19AuthPluginInterface13statusChangedE15AuthPluginStateRK7QString@Base 8.57+20150423 _ZN19AuthPluginInterface16staticMetaObjectE@Base 8.57+20150423 - _ZN19AuthPluginInterface18userActionFinishedERKN6SignOn13UiSessionDataE@Base 8.57+20150423 + (optional) _ZN19AuthPluginInterface18userActionFinishedERKN6SignOn13UiSessionDataE@Base 8.57+20150423 _ZN19AuthPluginInterface18userActionRequiredERKN6SignOn13UiSessionDataE@Base 8.57+20150423 - _ZN19AuthPluginInterface5abortEv@Base 8.57+20150423 + (optional) _ZN19AuthPluginInterface5abortEv@Base 8.57+20150423 _ZN19AuthPluginInterface5errorERKN6SignOn5ErrorE@Base 8.57+20150423 _ZN19AuthPluginInterface5storeERKN6SignOn11SessionDataE@Base 8.57+20150423 - _ZN19AuthPluginInterface6cancelEv@Base 8.57+20150423 + (optional) _ZN19AuthPluginInterface6cancelEv@Base 8.57+20150423
Bug#1057750: ciso: Please update to ciso 1.0.2
Debdiff prepared and attached. Please review this whenever you get a
chance and tell me if there's anything I can do better. Thanks!
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
diff -Nru ciso-1.0.0/README.markdown ciso-1.0.2/README.markdown
--- ciso-1.0.0/README.markdown 1970-01-01 00:00:00.0 +
+++ ciso-1.0.2/README.markdown 2015-07-07 18:05:38.0 +
@@ -0,0 +1,24 @@
+ciso is a simple commandline utility to compress PSP iso files.
+
+This package is an OSX port of a package provided by Ubuntu: http://packages.ubuntu.com/search?keywords=ciso
+
+# Installation
+
+Now available via homebrew:
+
+brew install ciso
+
+To build yourself, it's a very straightforward `make` (and optional `make install`).
+
+# Usage
+
+To decompress a cso file:
+
+ciso 0 infile.cso outfile.iso
+
+To compress an iso file:
+
+ciso level infile.iso outfile.cso
+
+where level ranges from 1 (fast, poor compression) to 9 (slow, high
+compression).
diff -Nru ciso-1.0.0/ciso.c ciso-1.0.2/ciso.c
--- ciso-1.0.0/ciso.c 2006-11-03 20:53:29.0 +
+++ ciso-1.0.2/ciso.c 2015-07-07 18:05:38.0 +
@@ -22,6 +22,7 @@
#include
#include
+#include
#include/* /usr(/local)/include/zlib.h */
#include
@@ -31,10 +32,10 @@
FILE *fin,*fout;
z_stream z;
-unsigned int *index_buf = NULL;
-unsigned int *crc_buf = NULL;
-unsigned char *block_buf1 = NULL;
-unsigned char *block_buf2 = NULL;
+uint32_t *index_buf = NULL;
+uint32_t *crc_buf = NULL;
+uint8_t *block_buf1 = NULL;
+uint8_t *block_buf2 = NULL;
/
compress ISO to CSO
@@ -43,9 +44,9 @@
CISO_H ciso;
int ciso_total_block;
-unsigned long long check_file_size(FILE *fp)
+uint64_t check_file_size(FILE *fp)
{
- unsigned long long pos;
+ uint64_t pos;
if( fseek(fp,0,SEEK_END) < 0)
return -1;
@@ -80,9 +81,9 @@
/
int decomp_ciso(void)
{
- unsigned long long file_size;
- unsigned int index , index2;
- unsigned long long read_pos , read_size;
+ uint64_t file_size;
+ uint32_t index , index2;
+ uint64_t read_pos , read_size;
int total_sectors;
int index_size;
int block;
@@ -117,7 +118,7 @@
ciso_total_block = ciso.total_bytes / ciso.block_size;
/* allocate index block */
- index_size = (ciso_total_block + 1 ) * sizeof(unsigned long);
+ index_size = (ciso_total_block + 1 ) * sizeof(uint32_t);
index_buf = malloc(index_size);
block_buf1 = malloc(ciso.block_size);
block_buf2 = malloc(ciso.block_size*2);
@@ -138,7 +139,7 @@
/* show info */
printf("Decompress '%s' to '%s'\n",fname_in,fname_out);
- printf("Total File Size %ld bytes\n",ciso.total_bytes);
+ printf("Total File Size %lld bytes\n",ciso.total_bytes);
printf("block size %d bytes\n",ciso.block_size);
printf("total blocks%d blocks\n",ciso_total_block);
printf("index align %d\n",1<
+
+#ifndef __CISO_H__
+#define __CISO_H__
+/*
+ complessed ISO(9660) header format
+*/
+typedef struct ciso_header
+{
+ uint8_t magic[4]; /* +00 : 'C','I','S','O' */
+ uint32_t header_size; /* +04 : header size (==0x18)*/
+ uint64_t total_bytes; /* +08 : number of original data size*/
+ uint32_t block_size; /* +10 : number of compressed block size */
+ uint8_t ver;/* +14 : version 01 */
+ uint8_t align; /* +15 : align of index value*/
+ uint8_t rsv_06[2]; /* +16 : reserved*/
+#if 0
+// INDEX BLOCK
+ uint32_t index[0]; /* +18 : block[0] index */
+ uint32_t index[1]; /* +1C : block[1] index */
+ :
+ :
+ uint32_t index[last]; /* +?? : block[last] */
+ uint32_t index[last+1]; /* +?? : end of last data point */
+// DATA BLOCK
+ uint8_t data[]; /* +?? : compressed or plain sector data */
+#endif
+}CISO_H;
+
+/*
+note:
+
+file_pos_sector[n] = (index[n]&0x7fff) << CISO_H.align
+file_size_sector[n] = ( (index[n+1]&0x7fff) << CISO_H.align) - file_pos_sector[n]
+
+if(index[n]&0x8000)
+ // read 0x800 without compress
+else
+ // read file_size_sector[n] bytes and decompress data
+*/
+
+#endif
-#ifndef __CISO_H__
-#define __CISO_H__
-/*
- complessed ISO(9660) header format
-*/
-typedef struct ciso_header
-{
- unsigned char magic[4]; /* +00 : 'C','I','S','O' */
- unsigned long header_size; /* +04 : header size (==0x18)*/
- unsigned long long total_bytes; /* +08 : number of original data size*/
- unsigned long block_size; /* +10 : number of compressed block size */
- unsigned char ver;/* +14 : version 01 */
- unsigned char align;
Bug#1057750: ciso: Please update to ciso 1.0.2
Package: ciso Version: 1.0.0-1 Severity: normal X-Debbugs-Cc: arraybo...@ubuntu.com ciso 1.0.0 has numerous coding issues resulting in a ton of compile-time warnings (mostly related to the fact that the author apparently forgot to include string.h). Version 1.0.2 fixes many of these issues, and also significantly improves code quality. I am preparing a debdiff that updates the package, and adds some packaging enhancements. -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-9-generic (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ciso depends on: ii libc6 2.38-3ubuntu1 ii zlib1g 1:1.2.13.dfsg-1ubuntu5 ciso recommends no packages. ciso suggests no packages.
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Alright, so apparently I can't read. I totally missed that you had mentioned there was already a bug report against Lintian about this problem. I think we probably should override the errors anyway for now since I am not an experienced Lintian or Perl developer and it will take me some time to try and get things fixed there, but I do agree with getting it fixed, and am happy to add this to my todo list and then help remove the overrides once the bug is fixed. As for not excluding the C-BIOS .xml files, I think it should be sufficient to simply change the file exclude pattern "Contrib/cbios" to "Contrib/cbios/*.rom" in debian/copyright. The change is minor enough I don't think it warrants a whole new debdiff attachment, though I'm happy to make one if it would make your life easier. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Is this bug something we're still actively working on? It's been a few days. If I missed something, feel free to let me know. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1057345: python-etcd3gw: Autopkgtest needs to depend on python3-all
Package: python-etcd3gw Severity: normal X-Debbugs-Cc: arraybo...@ubuntu.com Building python-etcd3gw from source on Debian Sid results in a Lintian warning, runtime-test-file-uses-supported-python-versions-without-python-all-build-depends. This is the result of the package python3-all not being present as a test prerequisite in debian/tests/control. Please add it as a Depends of the unittests test. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.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#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Sun, Dec 3, 2023 at 2:04 AM Dr. Bas Wijnen wrote: > > Hi, > > This is starting to look great, thanks a lot of all the work. :-) However, I > still see a few issues with it: > > - the references to C-BIOS in the XML configuration files should not be > removed. When running, they are usually availably from the cbios package. > And if the user didn't install that, OpenMSX will detect this and handle it > properly. Good to know, will fix. > - The bundled catch2 should not be used. So the proper solution would be to > port the code to the newer version, and to keep the bundled version out of > it. Using the bundled version is acceptable as a temporary solution, but if > we do that, we should file a bug report that the packaged version should be > used again. Well... I'm not sure I agree there. The reason we switched away from the bundled catch2 was because it wouldn't build due to a change in glibc, and that has now been fixed in the vendored catch2. But more importantly, openMSX upstream is still depending on catch2 v2, whereas the version of catch2 in Debian is now catch2 v3, which has quite a bit of breaking changes. While it is definitely possible to port the openMSX tests to use catch2 v3, we will be departing from what upstream supports, and that seems like it could lead to way more work than necessary (for instance, what if the next major release of openMSX still uses catch2 v2 and uses it in a way that's incompatible with catch2 v3? Then we have to maintain that delta from upstream ourselves, possibly for an extended period of time). One possible solution might be for Debian to ship multiple major versions of catch2. Then we could depend on a catch2-v2 package or something like that and avoid having to use the vendored one. Then when upstream switches to catch2 v3, we just change the dependency to catch2 (which would then be catch2 v3). IMO the catch2 package should have the equivalent of sonames since it acts very much like a library in the sense that there are API breaking changes between major versions... but that's not what Debian does with it at the moment, so we're stuck finding alternate solutions. Maybe this is something we can bring up to whoever maintains catch2 in Debian. > - I prefer to not override the source-is-missing lintian messages. The reason > is that there are 3 kinds of messages, each with their own solution: > > 1. An actual bug in the code. The solution is to fix the code. > 2. A bug in Lintian. This code should not trigger the message. The solution > is to fix Lintian. > 3. A special (and rare) case. This code should not trigger the message, but > it is unreasonable to expect Lintian to understand that. The solution is > to add an override. > > IMO what we have here is 2, not 3. Adding an override implies that there is > nothing wrong with Lintian's behavior, which is incorrect; there is a bug > filed against Lintian for this and it should be fixed there. Unused > overrides > can unexpectedly hide actual problems, so when it gets fixed in Lintian, the > overrides need to be removed, but it is unlikely that anyone will think of > this, because there will not be a notification that the bug is fixed. > > Because of all this, I prefer to not silence Lintian. The messages do > indicate an actual bug, it's just not in this package. I'm not so sure it's a Lintian bug since HTML files oftentimes *are* compiled from other source code. Perhaps there's some sort of heuristic there though (I've not looked at the Lintian code and I don't know Perl, so I'm not sure). > Thanks, > Bas > > On Wed, Nov 29, 2023 at 06:50:59PM -0600, Aaron Rainbolt wrote: > > Alright, here's the latest openMSX package with all C-BIOS binaries patched > > out. Now that there's no new binaries, I can just send this as a debdiff > > attachment. Keep in mind all the binary files mentioned in the diff have to > > be deleted from the source tree. > > > > Thanks for collaborating with me so we could come up with the best solution > > possible for this! The debdiff is attached. > > > > -- > > Aaron Rainbolt > > Lubuntu Developer > > Matrix: @arraybolt3:matrix.org > > IRC: arraybolt3 on irc.libera.chat > > GitHub: https://github.com/ArrayBolt3
Bug#1056897: [3dprinter-general] Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=()=?UTF-8?Q?’ is ambiguous
On 11/30/23 16:34, Gregor Riepl wrote: Hi Aaron, Simon is uploading the new packaging to the DELAYED/1 queue. It should arrive in the archive on November 30. If you are a maintainer of slic3r-prusa, you can review the new packaging in the mean time and reject or fast-track it as you see fit. Thanks a lot for this! The NMU is building right now. Unfortunately, it looks like a new issue cropped up that curiously didn't happen to me during testing: [1] ./tests/arrange/test_arrange.cpp:935: FAILED: REQUIRE_THAT( score, WithinRel(0., EPSILON) ) with expansion: -0.0 and 0 are within 0.01% of each other Sounds like the EPSILON value is not appropriate for this test, or WithinRel has problems with negative zero (or near-zero). Gah, looks like some arch-dependent glitch. Which explains why it didn't happen to either of us (we probably both used amd64 machines, I definitely did) and then the failure did happen upon publishing. Thanks for your help, I'll try to help get the next fix in once it's ready. I'll investigate this issue as soon as I can. Regards, Gregor [1] https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=arm64=2.6.1%2Bdfsg-4.1=1701382946=0 -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Alright, here's the latest openMSX package with all C-BIOS binaries patched out. Now that there's no new binaries, I can just send this as a debdiff attachment. Keep in mind all the binary files mentioned in the diff have to be deleted from the source tree. Thanks for collaborating with me so we could come up with the best solution possible for this! The debdiff is attached. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3 Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_basic.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_basic.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_disk.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_disk.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_logo_msx1.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_logo_msx1.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_logo_msx2.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_logo_msx2.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_logo_msx2+.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_logo_msx2+.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1_br.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1_br.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1_eu.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1_eu.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1_jp.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1_jp.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2_br.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2_br.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+_br.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+_br.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2_eu.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2_eu.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+_eu.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+_eu.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2_jp.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2_jp.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+_jp.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+_jp.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+.rom differ diff -Nru openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_BR.xml openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_BR.xml --- openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_BR.xml 2023-08-29 13:20:30.0 -0500 +++ openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_BR.xml 1969-12-31 18:00:00.0 -0600 @@ -1,78 +0,0 @@ - - - - - -C-BIOS -MSX1 BR -2010 -An MSX1 machine using C-BIOS, with Brazillian settings, like 60Hz interrupt frequency. -MSX - - - - - - - - - - - 583cda86979ff4cd1eef75e79c7fda96e425317a - cbios_main_msx1_br.rom - - - - - - - 9fbbe400dbaf186aeba42e170d9424b032412c42 - cbios_logo_msx1.rom - - - - - - - - - - - - - - - - - -16000 - - false - int - true - false - false - - - - - - TMS99X8A - 16 - - - - YM2149 - - -21000 - - - - - - - - - - diff -Nru openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_EU.xml openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_EU.xml --- openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_EU.xml 2023-08-29 13:20:30.0 -0500 +++ openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_EU.xml 1969-12-31 18:00:00.0 -0600 @@ -1,78 +0,0 @@ - - - - - -C-BIOS -MSX1 EU -2003 -An MSX1 machine using C-BIOS, with an international keyboard layout and 50Hz interrupt frequency. -MSX - - - - - - - - - - - baf2e9c69252fd9b350b488d89c71887b9d05eec - cbios_main_msx1_eu.rom - - - - - - - 9fbbe400dbaf186aeba42e170d9424b032412c42
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 11/29/23 14:40, Bas Wijnen wrote: On Wed, Nov 29, 2023 at 01:52:46PM -0600, Aaron Rainbolt wrote: It appears that the C-BIOS package in Debian only ships the most recent C-BIOS files. I think we can't just depend on it for this reason, since the older C-BIOS ROMs are needed to avoid save state breakage. See Contrib/cbios-old/README in the openMSX package. Well, in that case that problem exists right now as well, as the openmsx package does not include any version of cbios; it just Depends: on the cbios package. Oy. I see that you're right (just tested it). While I'm not sure if this is something that requires fixing (I need to think more about that), the proper way to fix it would be inside the cbios package, I think. Those copies are only included in openmsx for convenience; the cbios package (including old versions of it) is the source for those binaries. If they need to be installed, it should be done from the package that has their source. Copying the source to also be available in the openmsx package (where the binaries aren't even used) doesn't make sense to me. Agreed. If the old save C-BIOS ROMs aren't being installed in the first place, there's no point in them (or their source) being there. So as far as the openmsx package is concerned, I think we should just remove the binaries from the source package. Then the next step is to solve this problem (or decide that it does not need solving) in the cbios package. I like it. I'll redo the packaging again to repack out the Contrib/cbios-old and Contrib/cbios directories (and get rid of the needless source code I added to debian/missing-sources), then upload the packaging to GitHub one more time for review. Thanks for your help! Thanks, Bas -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files()’ is ambiguous
Simon is uploading the new packaging to the DELAYED/1 queue. It should arrive in the archive on November 30. If you are a maintainer of slic3r-prusa, you can review the new packaging in the mean time and reject or fast-track it as you see fit. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files()’ is ambiguous
In two days slic3r-prusa is going to be removed from testing if this bug isn't fixed, since it's keeping the package from migrating, leaving an RC bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054697) unfixed even though it's been patched and uploaded. I am attempting to get a Debian Developer (Simon Quigley) to help me NMU Gregor's patch so we can get this fixed before December 1st. The packaging is complete and has been submitted to Simon for review. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
It appears that the C-BIOS package in Debian only ships the most recent C-BIOS files. I think we can't just depend on it for this reason, since the older C-BIOS ROMs are needed to avoid save state breakage. See Contrib/cbios-old/README in the openMSX package. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub:https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Wed, Nov 29, 2023 at 5:17 AM Dr. Bas Wijnen wrote: > > Hi, > > Thanks a lot for not just finding those issues, but also fixing them! That is > much appreciated. > > As for the license, Manuel (who is upstream) pointed out that the entire > source > code is (and always has been) GPL-2 only. The only issue with that is the > packaging, which is GPL-3+. But that was my doing; the original was GPL-2 (I > thought GPL-2+, but perhaps that isn't true and I wasn't even allowed to make > it GPL-3+). > > In any case, I'll happily change the license to my work into GPL-2+, so that > it > is compatible with the rest of OpenMSX. Obviously the link should also point > to > GPL-2. I don't think changing the packaging license now is necessary, and it may require a significant amount of extra work - other people have worked on the packaging since you first set its license, which means that changing that license would require a relicensing effort (contact all the previous packagers who made significant changes and ask for permission). Easier to just leave the packaging as GPL-3+, it won't do any harm and makes things simpler. > As for cbios: I was not aware that it was included in the source tree. Fact is > that it doesn't need to be; it is useful for running the system, but it is not > even required for that and it is also not required for compiling it. If it > were, I'd build-depend on the Debian package. > > So while I appreciate your efforts to track down and package the sources, I > think the better approach is to remove the binaries from Debian's source > package, just like the Windows dll. > > Do you agree that that would be a more elegant solution? Does the C-BIOS package contain multiple previous versions of C-BiOS, and put them where openMSX expects? openMSX has many older versions of C-BIOS included for loading older save states. It's possible this would be a workable solution, I'd just need to look at it a bit closer. We don't want to break people's old save states. If the C-BIOS package only ships the latest version of C-BIOS, then this solution will not work. If it ships all needed versions and has them in the right spots, then this would probably work.. > Thanks, > Bas > > On Mon, Nov 27, 2023 at 03:14:37PM -0600, Aaron Rainbolt wrote: > > On 11/27/23 15:02, Manuel Bilderbeek wrote: > > > On 27-11-2023 02:11, Aaron Rainbolt wrote: > > > > Alright, I have fully rebuilt the copyright file. I also ended up > > > > adding the source code for several releases of C-BIOS into the > > > > packaging. As this code is in the form of zipped files for the sake > > > > of size, it's not exactly practical to provide the new source > > > > package changes as a debdiff since debdiffs don't communicate binary > > > > file changes very well. So here's a .tar.gz of the new source > > > > package tree, detach-signed with my GPG key. > > > > https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub > > > > since Gmail didn't want to let me send the package as a file > > > > attachment.) > > > But why would you include the cbios sources in the openMSX package, as > > > there is already a cbios package, which provides the binaries and has > > > the sources as source package? > > > > Because openMSX vendors pre-built C-BIOS binaries, so therefore the source > > package must include the sources for it to be DFSG compliant. See > > https://www.debian.org/social_contract DFSG section 2. There is no build > > dependency on C-BIOS since C-BIOS binaries are provided in openMSX rather > > than sources. There is no binary dependency on C-BIOS either for the same > > reason. A user who downloads the source for the Debian openMSX package will > > not get all of the source, since there are multiple C-BIOS binaries with no > > source code. openMSX does point to the C-BIOS sources on SourceForge, but > > SourceForge isn't guaranteed to always exist. I do not think it is > > sufficient for some of the sources the user should have been given to just > > be "somewhere in the archive", leaving it up to the user to find them. > > Including C-BIOS source in the source package of openMSX ensures that even > > if all else fails (no upstream source, no way of pulling the C-BIOS source > > package for some reason) a user will always get the sources for the software > > they downloaded the source package of. > > > > > > > > > > (You probably will notice some superfluous-file-pattern warnings > > > > from Lintian when you build this - I do not understand why these are > > > > occurring as the file patterns it's griping about are *not* > > > > superfluous and don't appear to be overridden by any later > > > > statements in the copyright file. I suspect a Lintian bug here.) > > > > > > > > > > -- > > > Kind regards, > > > Manuel > > > > -- > > Aaron Rainbolt > > Lubuntu Developer > > Matrix: @arraybolt3:matrix.org > > IRC: arraybolt3 on irc.libera.chat > > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
I had a Debian Developer review my packaging work. I got the package version string wrong and was slightly vague about the debhelper version update in the changelog. Both of those things are now fixed and I have the fixed files pushed to the same GitHub repo as last time, https://github.com/ArrayBolt3/openmsx-packaging. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 11/27/23 15:02, Manuel Bilderbeek wrote: On 27-11-2023 02:11, Aaron Rainbolt wrote: Alright, I have fully rebuilt the copyright file. I also ended up adding the source code for several releases of C-BIOS into the packaging. As this code is in the form of zipped files for the sake of size, it's not exactly practical to provide the new source package changes as a debdiff since debdiffs don't communicate binary file changes very well. So here's a .tar.gz of the new source package tree, detach-signed with my GPG key. https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub since Gmail didn't want to let me send the package as a file attachment.) But why would you include the cbios sources in the openMSX package, as there is already a cbios package, which provides the binaries and has the sources as source package? Because openMSX vendors pre-built C-BIOS binaries, so therefore the source package must include the sources for it to be DFSG compliant. See https://www.debian.org/social_contract DFSG section 2. There is no build dependency on C-BIOS since C-BIOS binaries are provided in openMSX rather than sources. There is no binary dependency on C-BIOS either for the same reason. A user who downloads the source for the Debian openMSX package will not get all of the source, since there are multiple C-BIOS binaries with no source code. openMSX does point to the C-BIOS sources on SourceForge, but SourceForge isn't guaranteed to always exist. I do not think it is sufficient for some of the sources the user should have been given to just be "somewhere in the archive", leaving it up to the user to find them. Including C-BIOS source in the source package of openMSX ensures that even if all else fails (no upstream source, no way of pulling the C-BIOS source package for some reason) a user will always get the sources for the software they downloaded the source package of. (You probably will notice some superfluous-file-pattern warnings from Lintian when you build this - I do not understand why these are occurring as the file patterns it's griping about are *not* superfluous and don't appear to be overridden by any later statements in the copyright file. I suspect a Lintian bug here.) -- Kind regards, Manuel -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Alright, I have fully rebuilt the copyright file. I also ended up adding the source code for several releases of C-BIOS into the packaging. As this code is in the form of zipped files for the sake of size, it's not exactly practical to provide the new source package changes as a debdiff since debdiffs don't communicate binary file changes very well. So here's a .tar.gz of the new source package tree, detach-signed with my GPG key. https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub since Gmail didn't want to let me send the package as a file attachment.) (You probably will notice some superfluous-file-pattern warnings from Lintian when you build this - I do not understand why these are occurring as the file patterns it's griping about are *not* superfluous and don't appear to be overridden by any later statements in the copyright file. I suspect a Lintian bug here.) -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: Fwd: Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Failed to reply to the right address, so forwarding. -- Forwarded message - From: Aaron Rainbolt Date: Sun, Nov 26, 2023 at 1:30 PM Subject: Re: Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues) To: Manuel Bilderbeek Thanks! I was able to find the code for all ROMs and get it included, so C-BIOS is now no longer an issue. I still have quite a bit more code to look through so I'll probably take a while longer to get this done, but it's coming along nicely. On Sun, Nov 26, 2023 at 1:22 PM Manuel Bilderbeek wrote: > > On 26-11-2023 18:39, Aaron Rainbolt wrote: > > Further investigation trying to rebuild the copyright file has revealed more > binaries without source code (the C-BIOS ROMs for instance). So I'll have to > find the sources for those also. Thanks for your patience. > > The C-BIOS ROMs have their source code, see e.g. the cbios package in Debian, > which contains all info to the upstream sources. (As they're packaged > separately, they are not part of the openMSX (source) packages in Debian.) > > -- > Kind regards, > > Manuel Bilderbeek
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Further investigation trying to rebuild the copyright file has revealed more binaries without source code (the C-BIOS ROMs for instance). So I'll have to find the sources for those also. Thanks for your patience. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
My reasoning here is that the openMSX code specifies "Some source files contain a license notice; all other source files are licensed under the GNU Public License (GPL), of which you can find a copy in the file 'GPL.txt'." That file contains a GPL-2 license, so the repository-wide license is GPL-2. To me specifying it as such seemed reasonable, and Lintian was complaining that the package pointed to the /usr/share/common-licenses/GPL symlink, which insinuates that all of the source code is licensed as GPL version 3 and will be relicensed to a newer version of the GPL when that license is published and Debian introduces it. This is at least *more* accurate than what was there before. I do not disagree that this is only partially accurate as it places a blanket licensing statement over the entirety of the source code that individual files may override. Ideally the copyright file should be rebuilt from scratch by auditing the entirety of the openMSX source code licenses. I can do that if it would be helpful. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Uh... ok so apparently either Gmail or the Debian BTS ate my patch, so here's a second attempt, this time as a file attachment. Also, it appears that the openMSX maintainer's debian.org email address must be pointing to an Apple support address since I've now gotten two "Thank you for contacting us" emails from apple.com. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3 Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 +++ openmsx-19.1+dfsg/debian/changelog 2023-11-24 13:47:59.0 -0600 @@ -1,3 +1,25 @@ +openmsx (19.1+dfsg-2) unstable; urgency=medium + + * Override spurious source-is-missing Lintian errors. + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a +Debian build environment. + * Repack the upstream tarball to remove a prebuilt Windows binary. +(Closes: #1056780) + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. + * Remove debian/source/include-binaries, every file listed in it doesn't +exist. + * Make debian/copyright point to more specific license files in +/usr/share/common-licenses. + * Set 'Rules-Requires-Root: no' in debian/control. + * Use debhelper 13 rather than debhelper 10. + * Override spurious package-contains-documentation-outside-usr-share-doc +Lintian gripes. + * Created debian/upstream/metadata file. + * Switch back to using vendored catch2, the catch2 Debian package now ships +catch2 v3 whereas openMSX uses catch2 v2. + + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600 + openmsx (19.1-1) unstable; urgency=medium * New upstream release. diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat --- openmsx-19.1/debian/compat 2017-08-06 07:57:22.0 -0500 +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 @@ -1 +0,0 @@ -10 diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 @@ -2,9 +2,10 @@ Section: otherosfs Priority: optional Maintainer: Bas Wijnen -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2 +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev Standards-Version: 4.6.2 Homepage: https://openmsx.org +Rules-Requires-Root: no Package: openmsx Architecture: any diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 +++ openmsx-19.1+dfsg/debian/copyright 2023-11-24 13:47:59.0 -0600 @@ -2,29 +2,31 @@ Upstream-Name: openMSX Upstream-Contact: https://web.libera.chat/#openMSX Source: https://github.com/openMSX/openMSX/ +Files-Excluded: Contrib/codec/Win32/zmbv.dll Files: * Copyright: copyright © 2001-2021 by the openMSX developers. -License: GPL +License: GPL-2 This program is free software: you can redistribute it and/or modify it under the terms of any version of the GNU General Public License as published by the Free Software Foundation. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + Version 2 of the GPL can be found in + /usr/share/common-licenses/GPL-2. Files: debian/* Copyright: © 2004-2009, Joost Yervante Damad Copyright 2012-2021, Bas Wijnen + Copyright 2023, Aaron Rainbolt License: GPL-3+ This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + On Debian systems, the GPL version 3 can be found in + /usr/share/common-licenses/GPL-3. Files: src/serial/Midi_w32.* diff -Nru openmsx-19.1/debian/openmsx-data.lintian-overrides openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides --- openmsx-19.1/debian/openmsx-data.lintian-overrides 1969-12-31 18:00:00.0 -0600 +++ openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides 2023-11-24 13:47:59.0 -0600 @@ -0,0 +1,22 @@ +# All of these are either false positives or they describe what should go in the directories they are in. +openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/exte
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Here's a debdiff between the current version of the openMSX package and a proposed new version that fixes this bug. **Note**: It is necessary to also delete the Contrib/codec/Win32/zmbv.dll file in the source package tree (debdiffs don't seem to communicate deleted binary files very well). -- Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 +++ openmsx-19.1+dfsg/debian/changelog 2023-11-24 13:47:59.0 -0600 @@ -1,3 +1,25 @@ +openmsx (19.1+dfsg-2) unstable; urgency=medium + + * Override spurious source-is-missing Lintian errors. + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a + Debian build environment. + * Repack the upstream tarball to remove a prebuilt Windows binary. + (Closes: #1056780) + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. + * Remove debian/source/include-binaries, every file listed in it doesn't + exist. + * Make debian/copyright point to more specific license files in + /usr/share/common-licenses. + * Set 'Rules-Requires-Root: no' in debian/control. + * Use debhelper 13 rather than debhelper 10. + * Override spurious package-contains-documentation-outside-usr-share-doc + Lintian gripes. + * Created debian/upstream/metadata file. + * Switch back to using vendored catch2, the catch2 Debian package now ships + catch2 v3 whereas openMSX uses catch2 v2. + + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600 + openmsx (19.1-1) unstable; urgency=medium * New upstream release. diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat --- openmsx-19.1/debian/compat 2017-08-06 07:57:22.0 -0500 +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 @@ -1 +0,0 @@ -10 diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 @@ -2,9 +2,10 @@ Section: otherosfs Priority: optional Maintainer: Bas Wijnen -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2 +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev Standards-Version: 4.6.2 Homepage: https://openmsx.org +Rules-Requires-Root: no Package: openmsx Architecture: any diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 +++ openmsx-19.1+dfsg/debian/copyright 2023-11-24 13:47:59.0 -0600 @@ -2,29 +2,31 @@ Upstream-Name: openMSX Upstream-Contact: https://web.libera.chat/#openMSX Source: https://github.com/openMSX/openMSX/ +Files-Excluded: Contrib/codec/Win32/zmbv.dll Files: * Copyright: copyright © 2001-2021 by the openMSX developers. -License: GPL +License: GPL-2 This program is free software: you can redistribute it and/or modify it under the terms of any version of the GNU General Public License as published by the Free Software Foundation. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + Version 2 of the GPL can be found in + /usr/share/common-licenses/GPL-2. Files: debian/* Copyright: © 2004-2009, Joost Yervante Damad Copyright 2012-2021, Bas Wijnen + Copyright 2023, Aaron Rainbolt License: GPL-3+ This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + On Debian systems, the GPL version 3 can be found in + /usr/share/common-licenses/GPL-3. Files: src/serial/Midi_w32.* diff -Nru openmsx-19.1/debian/openmsx-data.lintian-overrides openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides --- openmsx-19.1/debian/openmsx-data.lintian-overrides 1969-12-31 18:00:00.0 -0600 +++ openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides 2023-11-24 13:47:59.0 -0600 @@ -0,0 +1,22 @@ +# All of these are either false positives or they describe what should go in the directories they are in. +openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/extensions/README] +openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/machines/Boosted_MSX2+_JP.
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Package: openmsx Version: 19.1-1 Severity: serious Justification: Policy 2.2.1 X-Debbugs-Cc: arraybo...@ubuntu.com Packages in the Debian `main` archive area *must* comply with the DFSG, of which section 2 states "The program must include source code, and must allow distribution in source code as well as compiled form." The openMSX package currently ships a Windows library (Contrib/codec/Win32/zmbv.dll) allegedly built from code that is part of DOSBox. The source code of the library is not included, and the library is fairly useless in Debian for obvious reasons. On top of this, there are a number of packaging issues that could be improved but that aren't so serious - the most problematic of these is an autopkgtest failure caused by catch2 (Debian currently ships catch2 v3, but openMSX's tests are only designed for catch2 v2 - thankfully there's a vendored version of catch2 in openMSX that builds successfully on Debian Sid now). As there does not appear to be a VCS link to the openMSX packaging in tracker.debian.org, I'm assuming openMSX isn't in Debian Salsa yet, and will provide a debdiff in this bug report. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 openmsx depends on: ii cbios 0.29a-1 ii libasound2 1.2.10-1 ii libc6 2.37-12 ii libgcc-s1 13.2.0-7 ii libgl1 1.7.0-1 ii libglew2.2 2.2.0-4+b1 ii libogg01.3.5-3 ii libpng16-161.6.40-2 ii libsdl2-2.0-0 2.28.5+dfsg-2 ii libsdl2-ttf-2.0-0 2.20.2+dfsg-1 ii libstdc++6 13.2.0-7 ii libtcl8.6 8.6.13+dfsg-2 ii libtheora0 1.1.1+dfsg.1-16.1+b1 ii libvorbis0a1.3.7-1 ii openmsx-data 19.1-1 ii zlib1g 1:1.3.dfsg-3 openmsx recommends no packages. Versions of packages openmsx suggests: pn dmktools pn openmsx-catapult pn openmsx-debugger -- no debconf information
Bug#1033719: libmate-desktop-2-17: Use-after-free condition in blow_expensive_caches() in mate-bg.c
Package: libmate-desktop-2-17
Version: 1.26.0-1
Severity: important
Tags: upstream patch
X-Debbugs-Cc: arraybo...@ubuntu.com
libmate-desktop has a use-after-free condition in which an item in a GList is
deleted and then dereferenced in a later loop iteration. This appears to have
been the result of a coding error upstream, and was later reverted. Debian
still has the buggy version of the code.
In Ubuntu, the buggy code caused the MATE application menu to vanish very soon
after clicking it. Desktop icons also vanished. I do not know if this is
happening to Debian or not, however since the buggy code is in Debian I
believe it's at least a risk even if it's not actively happening. This was
reported as https://launchpad.net/bugs/2013138
The following patch looks like it should be easily applicable to Debian, and
it solves the bug in Ubuntu:
diff --git a/libmate-desktop/mate-bg.c b/libmate-desktop/mate-bg.c
index 0f617fa..e535231 100644
--- a/libmate-desktop/mate-bg.c
+++ b/libmate-desktop/mate-bg.c
@@ -2002,19 +2002,18 @@ static gboolean
blow_expensive_caches (gpointer data)
{
MateBG *bg = data;
- GList *list;
+ GList *list, *next;
bg->blow_caches_id = 0;
- if (bg->file_cache) {
- for (list = bg->file_cache; list != NULL; list = list->next) {
- FileCacheEntry *ent = list->data;
+ for (list = bg->file_cache; list != NULL; list = next) {
+ FileCacheEntry *ent = list->data;
+ next = list->next;
- if (ent->type == PIXBUF) {
- file_cache_entry_delete (ent);
- bg->file_cache = g_list_delete_link (bg->file_cache,
- list);
- }
+ if (ent->type == PIXBUF) {
+ file_cache_entry_delete (ent);
+ bg->file_cache = g_list_delete_link (bg->file_cache,
+ list);
}
}
Patch source:
https://git.mate-desktop.org/mate-desktop/commit/?id=7b379f54a5b09df007f7e84dabbbc5f8ce9381a9
(And yes, I do realize that is formatted horribly, but that's what upstream
MATE's website gave me. I think it trimmed off a bunch of preceeding
whitespace for some reason.)
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-32-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libmate-desktop-2-17 depends on:
ii iso-codes 4.9.0-1
ii libatk1.0-0 2.36.0-3build1
ii libc6 2.35-0ubuntu3.1
ii libcairo2 1.16.0-5ubuntu2
ii libdconf1 0.40.0-3
ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1ubuntu0.2
ii libglib2.0-0 2.72.4-0ubuntu1
ii libgtk-3-03.24.33-1ubuntu2
ii libpango-1.0-01.50.6+ds-2ubuntu1
ii libstartup-notification0 0.12-6build2
ii libx11-6 2:1.7.5-1
ii libxrandr22:1.5.2-1build1
libmate-desktop-2-17 recommends no packages.
libmate-desktop-2-17 suggests no packages.
Bug#1033385: openbox: Openbox crashes when switching out of a fullscreen window (requires GLib 2.76.0 to reproduce)
Package: openbox
Severity: important
Tags: patch upstream
X-Debbugs-Cc: arraybo...@ubuntu.com
This bug currently does not affect Debian with the current version of GLib in
the Debian archives. However, when Debian upgrades to GLib 2.75.0 or later,
this will almost certainly start happening.
In at least GLib 2.75.0 (possibly earlier but I'm not sure), the slice
allocator has been removed. This theoretically should not cause problems,
however it is revealing memory management problems in a number of apps, one of
which is Openbox. The commit removing the slice allocator is:
https://gitlab.gnome.org/GNOME/glib/-/commit/45b5a6c1e56d5b73cc5ed798ef59a5601e56c170
The offending function in Openbox:
-
void client_calc_layer(ObClient *self)
{
GList *it;
/* skip over stuff above fullscreen layer */
for (it = stacking_list; it; it = g_list_next(it))
if (window_layer(it->data) <= OB_STACKING_LAYER_FULLSCREEN) break;
/* find the windows in the fullscreen layer, and mark them not-visited */
for (; it; it = g_list_next(it)) {
if (window_layer(it->data) < OB_STACKING_LAYER_FULLSCREEN) break;
else if (WINDOW_IS_CLIENT(it->data))
WINDOW_AS_CLIENT(it->data)->visited = FALSE;
}
client_calc_layer_internal(self);
/* skip over stuff above fullscreen layer */
for (it = stacking_list; it; it = g_list_next(it))
if (window_layer(it->data) <= OB_STACKING_LAYER_FULLSCREEN) break;
/* now recalc any windows in the fullscreen layer which have not
had their layer recalced already */
for (; it; it = g_list_next(it)) {
if (window_layer(it->data) < OB_STACKING_LAYER_FULLSCREEN) break;
else if (WINDOW_IS_CLIENT(it->data) &&
!WINDOW_AS_CLIENT(it->data)->visited)
client_calc_layer_internal(it->data);
}
}
-
Notice in particular the "client_calc_layer_internal(it->data)" call. This
function calls code that proceeds to remove the list item that "it"
references. This renders "it" invalid. On the next iteration through the loop,
the now-invalid "it" pointer is used as if it were still valid (walking to the
next element in the list and then dereferencing it). When "it" is dereferenced
in the window_layer(it->data) call, Openbox crashes with a segmentation fault.
This bug has been reported upstream at
https://bugzilla.icculus.org/show_bug.cgi?id=6669. The following patch is
provided to fix the bug, and has been accepted into a developer's work branch
here:
http://git.openbox.org/?p=mikachu/openbox.git;a=commit;h=d41128e5a1002af41c976c8860f8299cfcd3cd72
-
diff --git a/openbox/client.c b/openbox/client.c
index 3ff278ae..ac4ff827 100644
--- a/openbox/client.c
+++ b/openbox/client.c
@@ -2702,9 +2702,10 @@ static void client_calc_layer_internal(ObClient *self)
void client_calc_layer(ObClient *self)
{
GList *it;
+GList *list = g_list_copy(stacking_list);
/* skip over stuff above fullscreen layer */
-for (it = stacking_list; it; it = g_list_next(it))
+for (it = list; it; it = g_list_next(it))
if (window_layer(it->data) <= OB_STACKING_LAYER_FULLSCREEN) break;
/* find the windows in the fullscreen layer, and mark them not-visited */
@@ -2717,7 +2718,7 @@ void client_calc_layer(ObClient *self)
client_calc_layer_internal(self);
/* skip over stuff above fullscreen layer */
-for (it = stacking_list; it; it = g_list_next(it))
+for (it = list; it; it = g_list_next(it))
if (window_layer(it->data) <= OB_STACKING_LAYER_FULLSCREEN) break;
/* now recalc any windows in the fullscreen layer which have not
@@ -2728,6 +2729,8 @@ void client_calc_layer(ObClient *self)
!WINDOW_AS_CLIENT(it->data)->visited)
client_calc_layer_internal(it->data);
}
+
+g_list_free(it);
}
gboolean client_should_show(ObClient *self)
-
I have verified that this does indeed fix the bug on Ubuntu (which uses GLib
2.75.0). It would likely be benefitial to Debian if this patch was applied
*before* Debian updates GLib to 2.75.0 or later, to avoid having these crashes
start happening.
I have not attempted to reproduce this bug on Debian, however since it is
known upstream and has a well-known cause and fix, I believe this is still
valid.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-32-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openbox depends on:
ii libc6 2.35-0ubuntu3.1
ii libglib2.0-0 2.72.4-0ubuntu1
ii
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
On 2/14/23 05:25, Jonathan Dowland wrote: On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote: If the XScreenSaver configuration file is included as a part of the core xscreensaver package itself, as a file that is simply unpacked, the following situation will result: … If the configuration file is split out into its own separate xscreensaver-config package … This is totally orthogonal to a solution to the bug reporter's issue. Splitting the xscreensaver package up and shipping the same files in different sub-packages and adding alternatives or other metapackage complications will do nothing to solve their problem. Your motivation for all that extra complexity is also orthogonal to Debian: you're talking about an enhancement for Ubuntu. As it stands, you're talking about making Debian worse to make Ubuntu better, and that's a hard sell. I don't really understand the purpose of this message - the bug report is closed and a solution was already uploaded. -- Aaron Rainbolt Lubuntu Developer https://github.com/ArrayBolt3 https://launchpad.net/~arraybolt3 @arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat OpenPGP_0x6169B9B4248C0464.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
(When am I going to start using the right email address? For crying out loud, Thunderbird.) On 1/21/23 21:11, Jamie Zawinski wrote: No. There should be exactly one XScreenSaver package. So, so many problems have stemmed from this incomplete, broken installations as a result of this ridiculous extras-data-extras-gl-extras-extras nonsense. I am decades weary of hearing about them. lol, to be fair, I don't fully understand what is with all of the tons of "extras" packages either. And I've not been around for long enough to know what all the pros and cons are. But I think that's beside the point for this particular situation. If the XScreenSaver configuration file is included as a part of the core xscreensaver package itself, as a file that is simply unpacked, the following situation will result: 1. There will be exactly one possible configuration file that ships with the defaults generated at compile time. 2. That file will become the only possible file that can be shipped in that location. 3. Any attempt to install a package which contains a customized version of that file will fail and cause a broken installation/upgrade attempt due to the file conflict. This technically might be able to be worked around by using a postinst script to replace the file, but that is a very hacky solution to a problem apt already has the capability to solve on its own. (Plus this workaround goes against Debian policy.) If the configuration file is split out into its own separate xscreensaver-config package, and the core package is made to depend on the -config package, then: 1. The configuration file generated at compile time will be installed by default if a user installs xscreensaver themselves. 2. Software that ships a customized version of that file can also provide a configuration package that uses Conflicts/Provides to replace xscreensaver-config. 3. The package containing the customized file can then be installed instead of xscreensaver-config, all dependencies will be satisfied, and everything will work, but in the way that the file customizer intended. Yes, this comes with the con of having yet *another* package involved, but it has a clear, practical use case. If you have an idea for how else to allow the configuration file to be customized, that doesn't involve the addition of another package, that would be great. -- Aaron Rainbolt Lubuntu Developer https://github.com/ArrayBolt3 https://launchpad.net/~arraybolt3 @arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
On 1/21/23 19:36, Jamie Zawinski wrote: Yes, it is critical that the version of /usr/lib/X11/app-defaults/XScreenSaver actually correspond to the version of XScreenSaver that is installed. I would have thought this to be obvious. If the file does not exist at all, things *should* work ok, but having an old version there is definitely going to screw everything up. So just install it. Any solution that involves *increasing* rather than *decreasing* the number of packages that comprise XScreenSaver is an asinine solution. I disagree that increasing the number of packages is a bad thing - if the core xscreensaver package includes the configuration file in question, it makes it difficult for a different package to ship the same file. For instance, lubuntu-default-settings in Ubuntu ships this file, with special customizations that make sense for Lubuntu but probably don't make a whole lot of sense for Debian or even for other flavors of Ubuntu. Having a separate xscreensaver-config package allows other packages to ship this file with specific customizations. While Debian doesn't have lubuntu-default-settings to contend with, it's not beyond possibility that other packages in the future might want to customize that file, and it's already the case that downstream Debian derivatives want to customize this file.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Actually, it dawns on me that the whole "virtual package" thing is overly complicated - just making an xscreensaver-config package should be good enough, and anything that needs to replace it can use a Conflicts/Provides to replace it.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Package: xscreensaver Version: 6.02+dfsg1-2+b1 Followup-For: Bug #1014782 X-Debbugs-Cc: arraybo...@ubuntu.com I can verify that this is still happening with a fully updated Debian Sid VM running IceWM. Myself and the Lubuntu Development team encountered this bug in Lubuntu, and it was determined that the problem was a faulty configuration file at /usr/lib/X11/app-defaults/XScreenSaver. If the file at this location is not configured properly, various functionality of XScreenSaver 6.02 may break, including (but not necessarily limited to) the Preview button. After rewriting the configuration file to be compatible with the XScreenSaver 6.02, all functionality was restored. The exact file Lubuntu 23.04 currently uses is at https://git.lubuntu.me/Lubuntu/lubuntu-default-settings/src/branch/ubuntu/lunar/src/usr/lib/X11/app-defaults/XScreenSaver Currently, the latest version of XScreenSaver in Debian does not ship a configuration file in this location at all. I believe this is likely the reason for this bug. I believe that, by default, when XScreenSaver is installed from source code, an auto-generated configuration file is written to the correct location. I suspect it has been disabled or omitted either by accident or for some reason, or possibly included in a package that is not being installed by default. My suggested fix would be to cause the automatically generated configuration file to be included as part of a package, "xscreensaver-config". This package would also provide a virtual package, "xscreensaver-conf" (or something similarly named). xscreensaver could then depend on xscreensaver-conf, which I believe would cause it to pull in xscreensaver-config by default, fixing the bug. This will allow any future packages that want to provide an XScreenSaver configuration file to do so (for instance, Lubuntu ships a customized XScreenSaver configuration file and would benefit from this). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.65.2 ii libatk1.0-0 2.46.0-4 ii libc62.36-8 ii libcrypt11:4.4.33-2 ii libglib2.0-0 2.74.5-1 ii libgtk2.0-0 2.24.33-2 ii libpam0g 1.5.2-6 ii libpango-1.0-0 1.50.12+ds-1 ii libsystemd0 252.4-1 ii libx11-6 2:1.8.3-3 ii libxext6 2:1.3.4-1+b1 ii libxft2 2.3.6-1 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxml2 2.9.14+dfsg-1.1+b2 ii libxrandr2 2:1.5.2-2+b1 ii libxt6 1:1.2.1-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data6.02+dfsg1-2+b1 Versions of packages xscreensaver recommends: ii gsfonts-x11 2:20200910-6 ii libjpeg-turbo-progs 1:2.1.2-1+b1 ii perl 5.36.0-7 ii wamerican [wordlist] 2020.12.07-2 Versions of packages xscreensaver suggests: pn fortune pn gdm3 | kdm-gdmcompat pn qcam | streamer pn www-browser pn xdaliclock pn xfishtank pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information
Bug#1021032: vlc: playing mp4 videos results in a black screen
Package: vlc Version: 3.0.17.4-4+b2 Severity: important X-Debbugs-Cc: arraybo...@gmail.com Dear Maintainer, When attempting to play back MP4 videos using VLC, only a black screen is displayed, sometimes with the VLC logo still slightly visible in the background. This problem appears to have been caused by the introduction of ffmpeg5 into Debian. Steps to reproduce: 1. Download a .mp4 video. Any video should work, I personally use drone footage from Pexels. 2. Open the video using VLC. Using Media -> Open File... from within the GUI works, as well as using the command line (vlc ./video.mp4). Expected result: The video should play back properly, allowing audio to be heard and video to be seen. Actual result: The screen remains black (or, if you open the video from the command line, the VLC logo can be seen dimly in the area where the video should be). The playback slider moves normally, as if the video was playing back properly. Additional notes: This bug was first discovered in Ubuntu 22.10 Kinetic Kudu, however it is also easily reproducible using Debian Sid. The bug exists both on physical and virtual hardware on Ubuntu, and I have been able to replicate it in a virtual machine on Debian. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vlc depends on: ii vlc-bin 3.0.17.4-4+b2 ii vlc-plugin-base 3.0.17.4-4+b2 ii vlc-plugin-qt3.0.17.4-4+b2 ii vlc-plugin-video-output 3.0.17.4-4+b2 Versions of packages vlc recommends: ii vlc-l10n 3.0.17.4-4 ii vlc-plugin-access-extra3.0.17.4-4+b2 ii vlc-plugin-notify 3.0.17.4-4+b2 ii vlc-plugin-samba 3.0.17.4-4+b2 ii vlc-plugin-skins2 3.0.17.4-4+b2 ii vlc-plugin-video-splitter 3.0.17.4-4+b2 ii vlc-plugin-visualization 3.0.17.4-4+b2 Versions of packages vlc suggests: pn vlc-plugin-fluidsynth pn vlc-plugin-jack pn vlc-plugin-pipewire pn vlc-plugin-svg Versions of packages libvlc-bin depends on: ii libc62.35-1 ii libvlc5 3.0.17.4-4+b2 Versions of packages libvlc5 depends on: ii libc62.35-1 ii libvlccore9 3.0.17.4-4+b2 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.17.4-4+b2 Versions of packages vlc-bin depends on: ii libc6 2.35-1 ii libvlc-bin 3.0.17.4-4+b2 ii libvlc5 3.0.17.4-4+b2 Versions of packages vlc-plugin-access-extra depends on: ii libc62.35-1 ii libsrt1.5-gnutls 1.5.1-1 ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.17.4-4+b2 ii libvncclient10.9.13+dfsg-4 ii libxcb-composite01.15-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-20 ii libarchive13 3.6.0-1 ii libaribb24-0 1.0.3-2 ii libasound2 1.2.7.2-1 ii libass9 1:0.16.0-1 ii libavahi-client3 0.8-6 ii libavahi-common3 0.8-6 ii libavc1394-0 0.5.4-5 ii libavcodec59 7:5.1.1-2+b1 ii libavformat597:5.1.1-2+b1 ii libavutil57 7:5.1.1-2+b1 ii libbluray2 1:1.3.3-1 ii libc62.35-1 ii libcairo21.16.0-6 ii libcddb2 1.3.2-7 ii libchromaprint1 1.5.1-2+b1 ii libdav1d61.0.0-2 ii libdbus-1-3 1.14.2-1 ii libdc1394-25 2.2.6-4 ii libdca0 0.0.7-2 ii libdvbpsi10 1.3.3-1 ii libdvdnav4 6.1.1-1 ii libdvdread8 6.1.3-1 ii libebml5 1.4.2-2+b1 ii libfaad2 2.10.0-2+b1 ii libflac8 1.3.4-2 ii libfontconfig1 2.13.1-4.5 ii libfreetype6 2.12.1+dfsg-3 ii libfribidi0 1.0.8-2.1 ii libgcc-s112.2.0-3 ii libgcrypt20 1.10.1-2 ii libglib2.0-0 2.74.0-2 ii libgnutls30 3.7.7-2 ii libgpg-error01.45-2 ii libharfbuzz0b5.2.0-2 ii libixml101:1.8.4-2 ii libjpeg62-turbo
