Bug#862957: file-roller: Fails to deal correctly with filename encodings in zip files
Charset issues are fixed in 7zip since https://salsa.debian.org/debian/7zip/-/merge_requests/8 Similar fix is suggested for unzip: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779207#61
Bug#779207: patch submission for improving code pages support in unzip
I slightly modified the patch for unzip:
1) Found a sample ANSI archive, which requires a separate code branch, so added
it (sample archive attached)
2) Fixed the -I and -O options, which were broken; they now mean the same thing
for all types of archives, both are left for compatibility, you can specify
either one. That is, they work similarly to -mcp in 7zip now
>Воскресенье, 26 мая 2024, 17:48 +02:00 от Ivan Sorokin :
>
>Dear colleagues,
>
>I am writing to bring to your attention an issue with the current upstream
>version of unzip that has not been updated for many years. In the modern
>environment, where the vast majority of systems use UTF-8, unzip exhibits
>several problems that need addressing:
>
>1) unzip is unable to correctly extract files containing the bit 11 in the
>General Purpose flag. This bit indicates that the file names are encoded in
>UTF-8. However, unzip attempts to re-encode them as if they are in OEM
>codepage, leading to incorrect file names.
>2) By default, unzip does not display UTF-8 encoding correctly on Unix systems.
>3) It is necessary to determine the OEM codepage correctly based on the system
>locale, rather than using a single codepage for all archives.
>4) The assumption that archives for which the legacy codepage cannot be
>determined are encoded in ISO 8859-1 is incorrect. In reality, most archivers
>used the user's system codepage, which could be any codepage. It is reasonable
>not to alter the encoding in this case, ensuring that the archive can be
>opened at least on the same system where it was created. Additionally, options
>-O and -I have been added to specify the encoding manually.
>
>I have prepared a patch (based on a similar patch from Ubuntu, with
>significant enhancements) that addresses these issues. A significant
>difference from the Ubuntu patch is that my code is capable of selecting the
>OEM codepage based on the system locale, instead of assuming the
>Russian/Cyrillic CP866 codepage for all archives when the system is set to
>UTF-8.
>
>I hope you will find this patch useful.
>
>Best regards,
>Ivan Sorokin
>
>
From: Giovanni Scafora
Subject: unzip files encoded with non-latin, non-unicode file names
Last-Update: 2024-02-22
* Updated 2015-02-11 by Marc Deslauriers
to fix buffer overflow in charset_to_intern()
* Updated 2023-06-15 by Dominik Viererbe
to add documentation for `-I` and `-O` options (LP: #138307) and fixed
garbled output when `zipinfo` or `unzip -Z` is called without arguments
(LP: #1429939)
* Updated 2024-05-26 by Ivan Sorokin
to fix several problems in codepages support:
1) Fixed bit 11 of General purpose flag support on systems with UTF-8
system charset
2) Fixed OEM code page being always assumed Russian/Cyrillic CP866
on any UTF-8 system
3) Added proper OEM code page detection based on system locale setting
4) Removed translation from ISO 8859-1 to local charset;
assumption that any non-unicode archive uses it is for sure wrong
as it can be any charset used on archive creator's local system;
also do not treat PKZIP for UNIX 2.51 archives
as having ISO 8859-1 charset for the same reasons
5) Enabled UTF-8 output by default on Unix systems
6) Fixed support for some legacy ANSI archives
7) -I and -O for manually setting charset, they are just the same now,
for all types of archives with 1-byte charset,
both left for compatibility
--- a/INSTALL
+++ b/INSTALL
@@ -480,7 +480,7 @@ To compile UnZip, UnZipSFX and/or fUnZip (detailed instructions):
NO_WORKING_ISPRINT
The symbol HAVE_WORKING_ISPRINT enables enhanced non-printable chars
filtering for filenames in the fnfilter() function. On some systems
-(Unix, VMS, some Win32 compilers), this setting is enabled by default.
+(VMS, some Win32 compilers), this setting is enabled by default.
In cases where isprint() flags printable extended characters as
unprintable, defining NO_WORKING_ISPRINT allows to disable the enhanced
filtering capability in fnfilter(). (The ASCII control codes 0x01 to
--- a/fileio.c
+++ b/fileio.c
@@ -2144,9 +2144,15 @@ int do_string(__G__ length, option) /* return PK-type error code */
/* translate the text coded in the entry's host-dependent
"extended ASCII" charset into the compiler's (system's)
internal text code page */
-Ext_ASCII_TO_Native((char *)G.outbuf, G.pInfo->hostnum,
-G.pInfo->hostver, G.pInfo->HasUxAtt,
-FALSE);
+#if (defined(UNICODE_SUPPORT) && defined(UTF8_MAYBE_NATIVE))
+if (!G.pInfo->GPFIsUTF8 || !G.native_is_utf8) {
+#endif
+Ext_ASCII_TO_Native((char *)G.outbuf, G.pInfo->
Bug#779207: patch submission for improving code pages support in unzip
Dear colleagues,
I am writing to bring to your attention an issue with the current upstream
version of unzip that has not been updated for many years. In the modern
environment, where the vast majority of systems use UTF-8, unzip exhibits
several problems that need addressing:
1) unzip is unable to correctly extract files containing the bit 11 in the
General Purpose flag. This bit indicates that the file names are encoded in
UTF-8. However, unzip attempts to re-encode them as if they are in OEM
codepage, leading to incorrect file names.
2) By default, unzip does not display UTF-8 encoding correctly on Unix systems.
3) It is necessary to determine the OEM codepage correctly based on the system
locale, rather than using a single codepage for all archives.
4) The assumption that archives for which the legacy codepage cannot be
determined are encoded in ISO 8859-1 is incorrect. In reality, most archivers
used the user's system codepage, which could be any codepage. It is reasonable
not to alter the encoding in this case, ensuring that the archive can be opened
at least on the same system where it was created. Additionally, options -O and
-I have been added to specify the encoding manually.
I have prepared a patch (based on a similar patch from Ubuntu, with significant
enhancements) that addresses these issues. A significant difference from the
Ubuntu patch is that my code is capable of selecting the OEM codepage based on
the system locale, instead of assuming the Russian/Cyrillic CP866 codepage for
all archives when the system is set to UTF-8.
I hope you will find this patch useful.
Best regards,
Ivan Sorokin
From: Giovanni Scafora
Subject: unzip files encoded with non-latin, non-unicode file names
Last-Update: 2024-02-22
* Updated 2015-02-11 by Marc Deslauriers
to fix buffer overflow in charset_to_intern()
* Updated 2023-06-15 by Dominik Viererbe
to add documentation for `-I` and `-O` options (LP: #138307) and fixed
garbled output when `zipinfo` or `unzip -Z` is called without arguments
(LP: #1429939)
* Updated 2024-05-26 by Ivan Sorokin
to fix several problems in codepages support:
1) Fixed bit 11 of General purpose flag support on systems with UTF-8
system charset
2) Fixed OEM code page being always assumed Russian/Cyrillic CP866
on any UTF-8 system
3) Added proper OEM code page detection based on system locale setting
4) Removed translation from ISO 8859-1 to local charset;
assumption that any non-unicode archive uses it is for sure wrong
as it can be any charset used on archive creator's local system;
also do not treat PKZIP for UNIX 2.51 archives
as having ISO 8859-1 charset for the same reasons
5) Enabled UTF-8 output by default on Unix systems
--- a/INSTALL
+++ b/INSTALL
@@ -480,7 +480,7 @@ To compile UnZip, UnZipSFX and/or fUnZip (detailed instructions):
NO_WORKING_ISPRINT
The symbol HAVE_WORKING_ISPRINT enables enhanced non-printable chars
filtering for filenames in the fnfilter() function. On some systems
-(Unix, VMS, some Win32 compilers), this setting is enabled by default.
+(VMS, some Win32 compilers), this setting is enabled by default.
In cases where isprint() flags printable extended characters as
unprintable, defining NO_WORKING_ISPRINT allows to disable the enhanced
filtering capability in fnfilter(). (The ASCII control codes 0x01 to
--- a/fileio.c
+++ b/fileio.c
@@ -2144,9 +2144,15 @@ int do_string(__G__ length, option) /* return PK-type error code */
/* translate the text coded in the entry's host-dependent
"extended ASCII" charset into the compiler's (system's)
internal text code page */
-Ext_ASCII_TO_Native((char *)G.outbuf, G.pInfo->hostnum,
-G.pInfo->hostver, G.pInfo->HasUxAtt,
-FALSE);
+#if (defined(UNICODE_SUPPORT) && defined(UTF8_MAYBE_NATIVE))
+if (!G.pInfo->GPFIsUTF8 || !G.native_is_utf8) {
+#endif
+Ext_ASCII_TO_Native((char *)G.outbuf, G.pInfo->hostnum,
+G.pInfo->hostver, G.pInfo->HasUxAtt,
+FALSE);
+#if (defined(UNICODE_SUPPORT) && defined(UTF8_MAYBE_NATIVE))
+}
+#endif
#ifdef WINDLL
/* translate to ANSI (RTL internal codepage may be OEM) */
INTERN_TO_ISO((char *)G.outbuf, (char *)G.outbuf);
@@ -2258,8 +2264,14 @@ int do_string(__G__ length, option) /* return PK-type error code */
/* translate the Zip entry filename coded in host-dependent "extended
ASCII" into the compiler's (system's) internal text code page */
-Ext_ASCII_TO_Native(G.filename, G.pInfo->hostnum, G.pInfo->hostver,
-G.pInfo->HasUxAt
Bug#545151: (no subject)
Dear colleagues, I would like to present an additional argument in support of including the libnatspec package in the distribution. At the moment, at least two Debian packages contain code that addresses a similar task. These are the 7zip and far2l packages. Both applications use locale-to-OEM-codepage translation tables to work correctly with the code pages used for encoding filenames in some .zip archives. Including such tables in every application that works with .zip archives (and generally, with any files that may historically contain data in OEM or ANSI encoding, such as ID3 tags in some mp3 files) does not seem like the most logical solution, as any changes to the tables would require modifying each application individually. Based on this, I would propose including the package with the libnatspec library, which addresses the same task, in the distribution. I also know someone who is willing to maintain the package. Thank you! Best regards, Ivan Sorokin
Bug#779207: unzip fails to unpack filenames containing 'ä' 'ö' 'ü' -> results in "(invalid encoding)"
The built-in .zip archiver in older versions of Windows used DOS (OEM) or Windows (ANSI) code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant OEM or ANSI code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232 Sample archive showing this bug attached. It uses CP866 (often called DOS or OEM) for Cyrillic (Russian) letters. <>
Bug#1070074: several errors on tab completion
Package: bash-completion Version: 1:2.12.0-1 Upgrading from 1:2.11-8 to 1:2.12.0-1 causes several errors at tab completion or starting bash. ... bash: _comp_deprecate_func: command not found bash: _comp_deprecate_var: command not found bash: _comp_deprecate_var: command not found bash: _comp_deprecate_var: command not found bash: _comp_have_command: command not found bash: _comp_have_command: command not found ... Reverting to previous version didn't help. This was due to util-linux-extra being put on hold, since once I updated 2.40-5 -> 2.40-8 util-linux-extra util-linux eject bsdextrautils libsmartcols1 libblkid1 libmount1 mount libuuid1 util-linux libfdisk1 the problem went away. Probably some version dependency should be added. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1068467: libgl1-mesa-dri: GPU hangs and resets while playing 3D games on Framework Laptop 13, AMD Ryzen 7640U
On Fri, 05 Apr 2024 11:36:32 -0600 Ivan Stanton wrote: > Package: libgl1-mesa-dri > Version: 23.3.5-1 > Severity: important > > Dear Maintainer, > > I and some others have been unable to play 3D games or run GPU-intensive > software on the Framework Laptop 13 AMD 7040 Edition due to GPU resets > occurring while doing so. I've previously reported this to the Framework > Community forums: > > https://community.frame.work/t/solved-debian-12-on-laptop-13-ryzen-7640u-gpu-hangs-in-some-games/ > > And others have reported similar issues: > > https://community.frame.work/t/vram-is-lost-due-to-gpu-reset-followed-by-a-crash/ > >* What led up to the situation? I attempted to play the Steam version of > Garry's Mod. This also occurred with The Stanley Parable: Ultra Deluxe > (Steam), > DSDA Doom (from the Debian repo) and Xonotic (from flathub). All 3D games > seem > to be affected, and possibly other GPU-intensive applications. >* What exactly did you do (or not do) that was effective (or > ineffective)? I first encountered this bug on bookworm, with mesa > 22.3.6-1+deb12u1. Upgrading linux-firmware, both from upstream and from > testing, had no effect. Upgrading the kernel from backports had no effect. > Upgrading mesa, using the packages from trixie, made the crashes less frequent > but did not resolve the issue. After some A/B testing, the crash seems to be > resolved only by both upgrading mesa and setting the kernel parameter > amdgpu.sg_display=0, which judging by the kernel documentation, I should not > have to set unless there is a bug. It would also be nice to get this fixed for > Debian Stable users, if possible. >* What was the outcome of this action? A few seconds into the game, the > display froze (though audio kept playing). After a few seconds, it flickered > and the graphics became partially corrupted. About a minute later, I was > kicked to the login screen. >* What outcome did you expect instead? Game continues playing without any > graphical glitches or freezes. > > I'm not an expert on the GNU/Linux graphics stack and I haven't reported a bug > to Debian in a while, so apologies if I got something wrong. > > Here's an extract of dmesg from one occurrence of the bug: > > [ 62.824231] amdgpu :c1:00.0: amdgpu: [gfxhub] page fault (src_id:0 > ring:24 vmid:6 pasid:32787, for process dsda-doom pid 2910 thread dsda- > doom:cs0 > pid 2926) > [ 62.824267] amdgpu :c1:00.0: amdgpu: in page starting at address > 0x00409b40c000 from client 10 > [ 62.824285] amdgpu :c1:00.0: amdgpu: > GCVM_L2_PROTECTION_FAULT_STATUS:0x00601030 > [ 62.824297] amdgpu :c1:00.0: amdgpu: Faulty UTCL2 client ID: TCP > (0x8) > [ 62.824310] amdgpu :c1:00.0: amdgpu: MORE_FAULTS: 0x0 > [ 62.824321] amdgpu :c1:00.0: amdgpu: WALKER_ERROR: 0x0 > [ 62.824331] amdgpu :c1:00.0: amdgpu: PERMISSION_FAULTS: 0x3 > [ 62.824340] amdgpu :c1:00.0: amdgpu: MAPPING_ERROR: 0x0 > [ 62.824349] amdgpu :c1:00.0: amdgpu: RW: 0x0 > [ 72.941268] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 I haven't been able to replicate this exact behavior since upgrading to Framework's BIOS version 3.05b and disabling all of my previous workarounds, but I did get this log from a regular app crash that was similar: [75883.804346] amdgpu :c1:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32807, for process Discord pid 8547 thread Discord:cs0 pid 8579) [75883.804356] amdgpu :c1:00.0: amdgpu: in page starting at address 0x4d023e345000 from client 10 [75883.804359] amdgpu :c1:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS: 0x00201430 [75883.804361] amdgpu :c1:00.0: amdgpu: Faulty UTCL2 client ID: SQC (data) (0xa) [75883.804363] amdgpu :c1:00.0: amdgpu: MORE_FAULTS: 0x0 [75883.804365] amdgpu :c1:00.0: amdgpu: WALKER_ERROR: 0x0 [75883.804368] amdgpu :c1:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [75883.804370] amdgpu :c1:00.0: amdgpu: MAPPING_ERROR: 0x0 [75883.804371] amdgpu :c1:00.0: amdgpu: RW: 0x0 [75893.925804] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered In this case, KWin reloaded due to a graphics reset, instead of logging me out, and I did not experience freezing.
Bug#1068467: libgl1-mesa-dri: GPU hangs and resets while playing 3D games on Framework Laptop 13, AMD Ryzen 7640U
Package: libgl1-mesa-dri Version: 23.3.5-1 Severity: important Dear Maintainer, I and some others have been unable to play 3D games or run GPU-intensive software on the Framework Laptop 13 AMD 7040 Edition due to GPU resets occurring while doing so. I've previously reported this to the Framework Community forums: https://community.frame.work/t/solved-debian-12-on-laptop-13-ryzen-7640u-gpu-hangs-in-some-games/ And others have reported similar issues: https://community.frame.work/t/vram-is-lost-due-to-gpu-reset-followed-by-a-crash/ * What led up to the situation? I attempted to play the Steam version of Garry's Mod. This also occurred with The Stanley Parable: Ultra Deluxe (Steam), DSDA Doom (from the Debian repo) and Xonotic (from flathub). All 3D games seem to be affected, and possibly other GPU-intensive applications. * What exactly did you do (or not do) that was effective (or ineffective)? I first encountered this bug on bookworm, with mesa 22.3.6-1+deb12u1. Upgrading linux-firmware, both from upstream and from testing, had no effect. Upgrading the kernel from backports had no effect. Upgrading mesa, using the packages from trixie, made the crashes less frequent but did not resolve the issue. After some A/B testing, the crash seems to be resolved only by both upgrading mesa and setting the kernel parameter amdgpu.sg_display=0, which judging by the kernel documentation, I should not have to set unless there is a bug. It would also be nice to get this fixed for Debian Stable users, if possible. * What was the outcome of this action? A few seconds into the game, the display froze (though audio kept playing). After a few seconds, it flickered and the graphics became partially corrupted. About a minute later, I was kicked to the login screen. * What outcome did you expect instead? Game continues playing without any graphical glitches or freezes. I'm not an expert on the GNU/Linux graphics stack and I haven't reported a bug to Debian in a while, so apologies if I got something wrong. Here's an extract of dmesg from one occurrence of the bug: [ 62.824231] amdgpu :c1:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:6 pasid:32787, for process dsda-doom pid 2910 thread dsda- doom:cs0 pid 2926) [ 62.824267] amdgpu :c1:00.0: amdgpu: in page starting at address 0x00409b40c000 from client 10 [ 62.824285] amdgpu :c1:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00601030 [ 62.824297] amdgpu :c1:00.0: amdgpu: Faulty UTCL2 client ID: TCP (0x8) [ 62.824310] amdgpu :c1:00.0: amdgpu: MORE_FAULTS: 0x0 [ 62.824321] amdgpu :c1:00.0: amdgpu: WALKER_ERROR: 0x0 [ 62.824331] amdgpu :c1:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [ 62.824340] amdgpu :c1:00.0: amdgpu: MAPPING_ERROR: 0x0 [ 62.824349] amdgpu :c1:00.0: amdgpu: RW: 0x0 [ 72.941268] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered [ 83.446602] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=7073, emitted seq=7075 [ 83.447891] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process dsda-doom pid 2910 thread dsda-doom:cs0 pid 2926 [ 83.448887] amdgpu :c1:00.0: amdgpu: GPU reset begin! [ 83.729405] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 83.730483] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 83.949833] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 83.950689] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 84.169971] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 84.170799] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 84.390063] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 84.390888] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 84.610016] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 84.610932] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 84.828847] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 84.830204] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 85.048322] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 85.049271] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue [ 85.267011] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 [ 85.268422] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]]
Bug#1068024: revert to version that does not contain changes by bad actor
> On 2024-03-30, Guillem Jover wrote: > On Sat, 2024-03-30 at 00:48:34 +, Stephan Verbücheln wrote: >> Subject: Re: Bug#1068024: Or remove xz altogether? >> Maybe the people who criticized xz back in the day for being an amateur >> project implementing a defective file format were right all along? >> https://www.nongnu.org/lzip/xz_inadequate.html > *Sigh*, the current situation is bad enough, and has nothing to do > with the xz format or design, or the FUD and propaganda from that > link. Please drop it… While I wouldn’t have brought it up myself, nor the arguably provocative Subject: change (reverted), as it’s indeed only tangentially related to the issue at hand (which apparently have resulted from the absense of good faith developers volunteering to maintain this project – and in a word of defense, the design quality of a software project /does/ influence both the amount of maintenance work and, other things being equal, the desire to get involved), the comment above got me curious: which parts of the document linked are ‘FUD and propaganda’? Because I’ve just glanced it over and I don’t find any obvious examples. Granted, I’m not an expert in the field of compression and coding, per se, and can’t readily speak on the validity of most of the arguments given there, those at least appear plausible. Some arguments I find obvious, such as, e. g.: ADD> A well-known property of CRCs is their ability to detect burst ADD> errors up to the size of the CRC itself. Using a CRC larger ADD> than the dataword is an error because a CRC just as large as ADD> the dataword equally detects all errors while it produces ADD> a lower number of false positives. If there’s a reasonable rebuttal to the points raised in that document, I believe that a pointer to it would be appropriate for this discussion. Other than that, I’m not going to go on this tangent any further here. I’ll be monitoring a handful of Internet fora for that, though (news:alt.os.linux.debian, news:comp.misc, irc://irc.efnet.org/%23coders, etc.) -- FSF associate member #7257 np. Moonsong — Shane Jackman
Bug#1064453: fdupes: Mistakenly assumes duplicates to have changed on armhf due to conflicting off_t definition
tags 1064453 + patch thanks The upstream fixed this by accident in either [1] (adding confing.h to fdupes.h) or [2] (adding config.h to removeifnotchanged.c). The attached patch fixes the problem on my armhf machine. -- Best regards, Ivan [1]: https://github.com/adrianlopezroche/fdupes/commit/ab5ef95e2b2633d0ca1a5ae0b8ac41abde160100#diff-6bb3626e773afb49e4d7267d0caa25a5d5b3f65d9705477654a5df6b95bcbe11 [2]: https://github.com/adrianlopezroche/fdupes/commit/8b223d6a2037b6c28d4c00b60dbc9d359309c07f#diff-4d4b4474dd3708d45d2c9ac887f496a3b16342221db4d139a8110c452e771b2a Description: Include config.h from fdupes.h The struct _file defined in fdupes.h contains members of type off_t. Depending on whether "config.h" is #included, this could resolve to different types. In particular, removeifnotchanged.c does not #include "config.h" and thus would get "corrupted" structs on systems where off_t is not 64-bit by default (like armhf). Author: Ivan Krylov Bug-Debian: https://bugs.debian.org/1064453 Forwarded: not-needed Last-Update: 2024-02-22 --- --- fdupes-2.2.1.orig/fdupes.h +++ fdupes-2.2.1/fdupes.h @@ -22,6 +22,7 @@ #ifndef FDUPES_H #define FDUPES_H +#include "config.h" #include #include "md5/md5.h"
Bug#1064453: fdupes: Mistakenly assumes duplicates to have changed on armhf due to conflicting off_t definition
Package: fdupes
Version: 1:2.2.1-1
Severity: normal
Dear Maintainer,
A script I am running on an armhf machine produces database snapshots.
Frequently, the snapshot is identical to the previous one, so I would
like to remove those using fdupes -qdN /path/to/dumps/.
After upgrading from Stretch to Bookworm (hitting all intermediate
releases in process), I started receiving the following output:
[+] /path/to/dumps/dump.2024-01-17_04:15:01.sql.xz
[!] /path/to/dumps/dump.2024-01-24_04:15:01.sql.xz -- unable to delete file:
File contents changed during processing!
[!] /path/to/dumps/dump.2024-01-31_04:15:01.sql.xz -- unable to delete file:
File contents changed during processing!
[!] /path/to/dumps/dump.2024-02-07_04:15:01.sql.xz -- unable to delete file:
File contents changed during processing!
[!] /path/to/dumps/dump.2024-02-21_04:15:01.sql.xz -- unable to delete file:
File contents changed during processing!
[!] /path/to/dumps/dump.2024-02-22_12:47:16.sql.xz -- unable to delete file:
File contents changed during processing!
Using GDB, I have traced this to the following situation: from fdupes.c, the
contents of dupelist look exactly right:
(gdb) frame 1
#1 0x004037e8 in deletefiles (files=0x42c7f8, prompt=0, tty=,
logfile=) at fdupes.c:1010
1010 if (removeifnotchanged(dupelist[x], ) == 0) {
(gdb) p *dupelist[x]
$47 = {d_name = 0x42c4d8 "/path/to/dumps/dump.2024-01-24_04:15:01.sql.xz", size
= 45664,
crcpartial = 0x423c68 "BD}\005\a\203\265H\004\204\206n\301T\343.15:0\031",
crcsignature = 0x423c98
"\232W\f\230B\2045\226\252\355\232Q\276\256\272ב\347U\342A\001", device = 2050,
inode = 41419299, mtime = 1706058902,
ctime = 1706058902, hasdupes = 0, duplicates = 0x42c390, next = 0x42c410}
The moment the execution reaches the function removeifnotchanged(), the
contents of dupelist start looking corrupted:
(gdb) frame 0
#0 removeifnotchanged (file=file@entry=0x42c490,
errorstring=errorstring@entry=0xbefff2d4) at removeifnotchanged.c:7
7 {
(gdb) p *file
$48 = {d_name = 0x42c4d8 "/path/to/dumps/dump.2024-01-24_04:15:01.sql.xz", size
= 0, crcpartial = 0xb260 ,
crcsignature = 0x0, device = 1864397139688, inode = 2050, mtime = 0,
ctime = 41419299, hasdupes = 0, duplicates = 0x65b06496, next = 0x65b06496}
The inode field now holds the value of the device field, and all the
pointers except the first one are plain wrong. This happens due to the
differences in the off_t type:
(gdb) frame 1
#1 0x004037e8 in deletefiles (files=0x42c7f8, prompt=0, tty=,
logfile=) at fdupes.c:1010
1010 if (removeifnotchanged(dupelist[x], ) == 0) {
(gdb) ptype /o dupelist[x]
type = struct _file {
/* 0 | 4 */char *d_name;
/* XXX 4-byte hole */
/* 8 | 8 */off_t size;
/* 16 | 4 */md5_byte_t *crcpartial;
/* 20 | 4 */md5_byte_t *crcsignature;
/* 24 | 8 */dev_t device;
/* 32 | 8 */ino_t inode;
/* 40 | 4 */time_t mtime;
/* 44 | 4 */time_t ctime;
/* 48 | 4 */int hasdupes;
/* 52 | 4 */struct _file *duplicates;
/* 56 | 4 */struct _file *next;
/* XXX 4-byte padding */
/* total size (bytes): 64 */
} *
(gdb) frame 0
#0 removeifnotchanged (file=file@entry=0x42c490,
errorstring=errorstring@entry=0xbefff2d4) at removeifnotchanged.c:7
7 {
(gdb) ptype /o file
type = const struct _file {
/* 0 | 4 */char *d_name;
/* 4 | 4 */off_t size;
/* 8 | 4 */md5_byte_t *crcpartial;
/* 12 | 4 */md5_byte_t *crcsignature;
/* 16 | 8 */dev_t device;
/* 24 | 4 */ino_t inode;
/* 28 | 4 */time_t mtime;
/* 32 | 4 */time_t ctime;
/* 36 | 4 */int hasdupes;
/* 40 | 4 */struct _file *duplicates;
/* 44 | 4 */struct _file *next;
/* total size (bytes): 48 */
} *
I think that fdupes.h must #include "config.h" in order to provide the
proper definition of off_t to every user of struct _file:
$ diff -u <(cpp removeifnotchanged.c) <((echo '#include "config.h"'; cat
removeifnotchanged.c) | cpp) | grep off_t
-typedef __off_t off_t;
+typedef __off64_t off_t;
-__off_t st_size;
-extern int fseeko (FILE *__stream, __off_t __off, int __whence);
-extern __off_t ftello (FILE *__stream) ;
The same problem may be present on other 32-bit architectures.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 4.14.180+ (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Bug#1057642: linux-image-6.5.0-5-amd64 still can't boot with Dell T140
Package: linux-image-6.5.0-5-amd64 Version: 6.5.13-1 The whole series of 6.5 kernels can't boot with Dell T140. Even this new version stops at loading initial ramdisk. Last working version was linux-image-6.4.0-4-amd64 6.4.13-1. Frank Lück reported to me personally « Hello, is seems to depend on the CPU. This one will only boot with DIS_UCODE_LDR in grub command line. cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz stepping: 3 microcode : 0x74 cpu MHz : 1200.082 cache size : 8192 KB » But this doesn't seem to be the case with my CPU, since adding DIS_UCODE_LDR doesn't make a difference. vendor_id : GenuineIntel cpu family : 6 model : 158 model name : Intel(R) Pentium(R) Gold G5420 CPU @ 3.80GHz stepping: 10 microcode : 0xf4 All possible firmware including BIOS were updated to the last available. hope it helps -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1056147: midge possibly contains non-DFSG-free examples
Control: tag -1 patch I have now uploaded a possible repackaged .orig.tar.bz2: http://users.am-1.org/~ivan/src/sfn.2xNKGoveuNoRGASEQosuADUES3vYQfQmWVeMuitdtLI.tar.bz2 It was produced with the following shell command (where 39 blocks starting with 180 cover the entirety of midge-0.2.41 /examples/covers/ directory in the Tar file.) $ (zcat | (dd count=180 ; dd count=39 > /dev/null ; dd) | bzip2 -4c) \ < midge_0.2.41.orig.tar.gz > midge_0.2.41+dfsg1.orig.tar.bz2 -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1056146: xsok possibly contains non-DFSG-free data files
Source: xsok
Version: 1.02-19
Severity: serious
Justification: possible DFSG violation
[Please do not Cc: me, as I’m “on the list,” so to say, and
I prefer to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]
The xsok debian/copyright file seems to suggest that xsok
was created solely by Michael Bischoff:
$ tar --xz -xO -- debian/copyright < xsok_1.02-19.debian.tar.xz
This is Debian GNU/Linux's prepackaged version of xsok.
xsok was written by Michael Bischoff .
The upstream source was downloaded from
ftp://ftp.io.com/pub/mirror/FreeBSD/ports/distfiles/xsok-1.02-src.tar.gz
The current Debian maintainer is Peter Samuelson .
Much of the packaging work was done by previous Debian maintainers
Sven Rudolph and Joel Rosdahl.
Copyright (c) 1994 by Michael Bischoff (m...@mo.math.nat.tu-bs.de)
[GNU GPL 2+ notice follows.]
There’re two issues with this. First, xsok includes
doc/cyberbox.doc, authored by Doug Beeferman (I presume
lib/Cyberbox/ files are also derivatives rather than
original xsok work.) The .doc file (quoted below) appears
to allow verbatim redistribution of the respective game,
but there’s no indication that ‘modifications and derived
works’ are allowed (as DFSG requires) as well:
S O R T A F R E E W A R E N O T I C E
This game can be distributed freely and played free of charge. If you like
it, however, I wouldn't mind a small donation for the effort I put into
writing the program and (ughh!) in making the levels. I say "ughh!" because
making the levels was by far the more time-consuming of the two projects.
Neither is there any such indication on http://dougb.com/ .
(I intend to contact the author of Cyberbox shortly to comment
on this issue and (or) possibly re-release at least the
portions of xsok derived from the original game in DFSG-
compliant fashion.)
Worse still, the ‘screens’ (= maps, levels) included in
lib/Sokoban/ appear to mostly come from the original,
proprietary version(s) of Soko-Ban. Consider, e. g.:
http://web.archive.org/web/2023/https://www.mobygames.com/game/1715/soko-ban/
http://web.archive.org/web/20230407165659im_/https://cdn.mobygames.com/8e54fc3c-bee0-11ed-9c42-02420a000140.webp
http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/0b7522d4-c204-11ed-ab6b-02420a000194.webp
The first Soko-Ban screen, identical to lib/Sokoban/screen.01 .
http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/058c7f98-ab6b-11ed-aaf5-02420a00019c.webp
The second Soko-Ban screen, identical to lib/Sokoban/screen.02 .
Moreover, taking a look at an earlier curses-based implementation
of the game from [1], which (according to its README.v2, as
quoted below) borrows screens from ‘the PC-version’, we find
out that likely /all/ levels from 1 to 50 inclusive are taken
from other software, while several other levels (86‒88) are
derived from the same.
I’m not aware of any evidence to suggest that the original
Soko-Ban might be out of copyright or ever released as free
software, from whence I conclude it’s likely proprietary,
including the level designs.
The first thing I have to say is that I don't have the sources for SOKOBAN
under MS-DOS. I believe that this program is copyrighted. I took only the
idea and the screens of the PC-version.
[1] http://ibiblio.org/pub/linux/games/strategy/sokoban-src.tar.gz
bash$ diff -dbuF^\; -- \
<((tar -zxOv --wildcards -- \*/screen.\? < sokoban-src.tar.gz ; \
tar -zxOv --wildcards -- \*/screen.\?\? < sokoban-src.tar.gz) \
2>&1 | sed -e "s,^sokoban.*\\.,;LEVEL ,;") \
share/games/xsok/Sokoban.def | head -n23
--- /dev/fd/63
+++ share/games/xsok/Sokoban.def2019-01-05 12:10:54 +
@@ -1,3 +1,14 @@
+;WALLS
+12 f f ff 0 standard floor
+. 13 f f ff 4 target field
+#0 0 00 0 walls
+
+;OBJECTS
+@0 f 0101 2011 0 player
+$1 f 0100 02 1000 heavy box
+
+;MAXLEVEL 88
+;ATOP *$.
;LEVEL 1
#
# #
@@ -759,3 +770,521 @@ ;LEVEL 50
# ### ## #
# # ###
##
+;LEVEL 51
+#
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#1056147: midge possibly contains non-DFSG-free examples
Source: midge Version: 0.2.41-4 Severity: serious Justification: possible DFSG violation [Please do not Cc: me, as I’m “on the list,” so to say, and I prefer to reserve my inbox for private communication only. I’d have set up Mail-Followup-To:, but there doesn’t seem to be a way to make it point to the report being filed.] The source currently contains a number of covers/*.mg files that are, so far as I can tell, derivatives of songs for which there’re no indication of being out of copyright or ever released under a DFSG-compliant license. In particular, a cursory look at Wikipedia articles (below) do not seem to mention anything related to possible free culture status of the songs transcribed in paranoid.mg & wish_you_were_here.mg. http://en.wikipedia.org/wiki/Paranoid_(Black_Sabbath_album) http://en.wikipedia.org/wiki/Wish_You_Were_Here_(Pink_Floyd_song) I believe the source needs to be repackaged so to exclude the examples/covers/ directory entirely. -- FSF associate member #7257 np. The Last Refugee — Roger Waters
Bug#1055788: linux-image-6.5.0-4-amd64 stop at loading initial ramdisk on Dell T140
Package: linux-image-6.5.0-4-amd64 Version: 6.5.3-4 Starting from linux-image-6.5.0-1-amd64 newer kernel simply stop booting when loading initial ramdisk. Reverting to linux-image-6.4.0-4-amd64 Version: (6.4.13-1) solve the problem. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1053347: newer 6.5 kernels still don't work on Dell T140
Hi, problem still persist with linux-image-6.5.0-3-amd64 BTW I don't know if since the package changed name it is still the right place to report any update. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1054377: Touchscreen doesn't wake up the system
Package: gnome Version: 1:43+1 I'm running Debian-12 (5.16.0-rc5) on arm64 architecture (Amlogic S905d3). Interacting with the touchscreen doesn't wake up the system, after it entered suspend state. As this is a tablet-like device, waking up on touch is a desired behavior. Is this gnome-shell issue or, perhaps, just a matter of configuration? I would appreciate some directions on solving this. Thanks in advance.
Bug#1053347: still not working on linux-image-6.5.0-2-amd64
Hi, just upgraded to linux-image-6.5.0-2-amd64 but same symptoms. Last working kernel was linux-image-6.4.0-4-amd64 thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1053347: linux-image-6.5.0-1-amd64 stop at loading initial ramdisk on Dell T140
Package: linux-image-6.5.0-1-amd64 Version: 6.5.3-1 Package simply stop booting when it is loading initial ramdisk. Reverting to linux-image-6.4.0-4-amd64 Version: (6.4.13-1) solve the problem. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1041373: toot: posts cannot begin with a hashtag
On Tue, 18 Jul 2023, at 08:58, debbug.t...@sideload.33mail.com wrote: > Package: toot > Version: 0.27.0-1 > > When posting from the commandline, if -e is used then a template > states that lines beginning with a hash (“#”) are ignored. This is a > problem because it’s very often useful to begin a line with a > hashtag. It’s in fact common to write just hashtags on the last line > of a message. This has been fixed in 0.28.1 (2022-11-12). -- Ivan
Bug#1040452: problem with locales with 2.37-4
I got some problems with locales upgrading from 2.37-3 to 2.37-4. Warning: Invalid locale (please review locale settings, this might lead to problems later): locale::facet::_S_create_c_locale name not valid and downgrading to 2.37-3 fixed the problem... if this can help to narrow down the possible causes. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1038004: confirmed + some reference
I've the same problem here and I've found https://forums.developer.nvidia.com/t/driver-470-182-03-fails-to-compile-with-linux-6-3-1/251992/2 that lead me to: https://gist.github.com/vejeta/9078219f082d2bfd62b08b6eada780e6 https://gist.github.com/joanbm/d10e9c8e245b6e7e27b2db338faf thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#741537: pssh: IPv6 host address processing broken
Preuße, Hilmar (2023-03-23 23:01:22 +0100) wrote: > On 13.03.2014 16:37, Ivan Vilata i Balaguer wrote: > > > The handling of IPv6 addresses is broken since the ``parse_host_entry()`` > > function in ``psshutil.py`` thinks the colons in it are an indication for a > > port and the last component is taken apart. Enclosing the address in > > brackets > > doesn't work either because the host name resolution includes the brackets > > around the IP address. > > > Upstream released version 2.3.5, which says "Fix IPv6 address as host". > I've put new packages on [1]. Could you check if they solve the issue? > > [1] https://freeshell.de/~hille42/pssh/ Thanks Hilmar, I tested the packages and: 1. A raw IPv6 address raises `ValueError` as it tries to parse the part after the 1st colon as a port. 2. A bracketed IPv6 works just fine. 3. A bracketed IPv6 plus `:PORT_NUMBER` raises `TypeError` in psshlib/task.py:40 as it tries to join the host string to the integer port. So I'd say that the original issue is fixed as per point 2, but using an alternative port will fail as per point 3 (though that wasn't part of the issue). Thanks you very much! -- Ivan Vilata i Balaguer -- https://elvil.net/
Bug#1034191: regression -6 broke what -5 fixed
Same problem with 5.15.8+dfsg-6, downgrading to 5.15.8+dfsg-5 fixed the problem. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1034191: Alt-F2 fail to open krunner
Package: libqt5gui5 Version: 5.15.8+dfsg-4 After upgrading from 5.15.8+dfsg-3 to 5.15.8+dfsg-4 opening krunner in lxqt doesn't work anymore. It doesn't seem to be a shortcut problem Alt-F1, F2 etc... works. Launching krunner from konsole get stuck with no debugging info. Downgrading fix the problem. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#980974:
Same problem here on Debian 11, will try the workaround and hope for the best. Huge time waste and disappointment though.. :/
Bug#1003865: interesting steps to fix it
I just stumbled in the same problem. I had to follow these step to actually fix this and it seems none can be skipped: 1 remove offending sources from /etc/apt/source.list 2 zap /var/lib/apt/lists 3 disable the proxy 4 apt update 5 add back the offending sources from /etc/apt/source.list 6 apt update 7 enable the proxy I had to put together all the receipt I found on the net to succeed. Removing the offending source, apt update, reenabling the offending source didn't work. (1 4 5 6) disabling the proxy alone didn't help 3. 2 3 4 5 didn't work either I had the chance to fix this on 2 machines and on the second one I tried to anticipate to re-enable the proxy just after putting back the sources (6) and it didn't work. I hope it helps to find the problem. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1030682: new version available
Package: edbrowse Version: 3.7.7-5 Severity: wishlist [Please do not Cc: me, as I’m “on the list,” so to say, and I try to reserve my inbox for private communication only. I’d have set up Mail-Followup-To:, but there doesn’t seem to be a way to make it point to the report being filed.] The latest version of Edbrowse currently tagged in the upstream Git repository is apparently v3.8.6. Could the Debian package please be updated? Are there other issues aside of the lack of a Debian QuickJS package? It seems to be rather straightforward to build, at least on a GNU/Linux system, and given it’s in pkgsrc [1] as well, I’d venture to guess it’s fairly portable in general. [1] http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/lang/quickjs/ (I suppose I can do the initial packaging, but not sure I’d be willing to maintain it. And even if I would, I’d need a sponsor still.) TYC. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1030681: man1/Xvnc symlink should be man1/Xvnc.1.gz
Package: tightvncserver Version: 1:1.3.10-6 Severity: minor Tags: patch [Please do not Cc: me, as I’m “on the list,” so to say, and I try to reserve my inbox for private communication only. I’d have set up Mail-Followup-To:, but there doesn’t seem to be a way to make it point to the report being filed.] Running the following command on a recent testing install reveals a misnamed man1/Xvnc symlink: $ find /usr/share/man -xdev -not -type d \ -regextype egrep -not -regex ".*/man([1-8])/[^/]*\\.\\1[a-z]*\\.gz" -ls 759686 0 lrwxrwxrwx 1 root root 27 Oct 15 2021 /usr/share/man/man1/Xvnc -> /etc/alternatives/Xvnc.1.gz $ This is apparently due to how update-alternatives(1) is invoked from .postinst: 16-update-alternatives --install \ 17- $BIN/XvncXvnc$BIN/Xtightvnc 70 \ 18- --slave \ 19: $MAN/XvncXvnc.1.gz $MAN/Xtightvnc.1.gz Compare with the invocation for the vncpasswd manual page: 20-update-alternatives --install \ 21-$BIN/vncpasswd vncpasswd$BIN/tightvncpasswd 70 \ 22---slave \ 23-$MAN/vncpasswd.1.gz vncpasswd.1.gz $MAN/tightvncpasswd.1.gz AIUI, at least the former line in debian/tightvncserver.postinst needs to be updated to use $MAN/Xvnc.1.gz in place of $MAN/Xvnc. I don’t seem to see in update-alternatives(1) whether it will automatically remove the older symlink upon the updated --install call above. If not, I presume the symlink will need to be removed in .postinst explicitly: ## This was a misnamed symlink created by older versions of the package rm -f -- "$MAN"/Xvnc Also while we’re at it, I’d like to suggest for all the variable substitutions in the code to be quoted like "$MAN" above. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1029511: still problems with returning type/type hints
Package: php-horde-imp Version: 6.2.27-2 Sorry if I can't point when this problem was introduced but I generally don't read email via the web interface and there was a configuration problem with horde syslogd that was hiding the problem. HORDE[3673]: [imp] TypeError: Return value of Horde_Imap_Client_Data_Acl::offsetGet() must be an instance of mixed, bool returned in /usr/share/php/Horde/Imap/Client/Data/Acl.php:112 This time mixed is clearly an error since in_array ALWAYS return a bool line 110 should be public function offsetGet($offset): bool fixing that another error came up trying to read any folder content HORDE[4304]: [imp] TypeError: Return value of Horde_Imap_Client_Fetch_Query::offsetGet() must be an instance of mixed, array returned in /usr/share/php/Horde/Imap/Client/Fetch/Query.php:316 This time it's hard to decide s I just went for the quick route of removing the type hint at line 312 public function offsetGet($offset) but then I got HORDE[3671]: [imp] TypeError: Return value of Horde_Imap_Client_Ids::key() must be an instance of mixed, int returned in /usr/share/php/Horde/Imap/Client/Ids.php:404 so I changed line 400 to public function key(): int this seems to work but I'm not sure if php consider null an int and again HORDE[558]: [imp] TypeError: Return value of Horde_Imap_Client_Ids::current() must be an instance of mixed, int returned in /usr/share/php/Horde/Imap/Client/Ids.php:395 fixed at 391 with public function current(): int but this too didn't stop the ordeal HORDE[4304]: [imp] TypeError: Return value of Horde_Imap_Client_Ids::key() must be of the type int, null returned in /usr/share/php/Horde/Imap/Client/Ids.php:404 So... php doesn't consider null as int... so line 400 changed to public function key() and I got this HORDE: [imp] TypeError: Return value of Horde_Imap_Client_Fetch_Query::key() must be an instance of mixed, int returned in /usr/share/php/Horde/Imap/Client/Fetch/Query.php:359 and since key() can return int or null... I went for killing the type hint at line 357 public function key() that lead me to HORDE[3673]: [imp] TypeError: Return value of Horde_Imap_Client_Fetch_Query::current() must be an instance of mixed, bool returned in /usr/share/php/Horde/Imap/Client/Fetch/Query.php:352 and since there is no easy way to guess what's going to be returned I killed the type hint at line 346 public function current() that lead me to HORDE[3669]: [imp] TypeError: Return value of Horde_Imap_Client_Fetch_Results::offsetGet() must be an instance of mixed, instance of Horde_Imap_Client_Data_Fetch returned in /usr/share/php/Horde/Imap/Client/Fetch/Results.php:146 and since again now I learnt that null is not equivalent to any type I killed the type hint at 142 public function offsetGet($offset) And finally at this point I could read email through the webmail without errors. I'm starting to be really confused about the use of those type hints and who and when they were added. Installing Horde from source seems to be a bit of a pain as well as putting Debian packaged version under version control to provide proper patches. But if I had a better understanding on why and how those type hints were added I could try to provide better corrections. They are plaguing the whole source base and they look like they have been put at random. I do feel the pain of choosing the correct type hint considering the starting point of the source base, but sabotaging the program doesn't seem the proper way to improve the source code and making it ready to move to php 8. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1028593: httpfs2: HTTPS URLs rejected, no httpfs2_ssl binary
Package: httpfs2 Version: 0.1.4-1.1 Severity: important Attempts to mount HTTPS URLs end with the following: $ httpfs2 https://www.example.org/ mnt Invalid protocol in url: https://www.example.org/ invalid url: https://www.example.org/ The manpage httpfs2(1) indicates that there should be support for HTTPS. There is no httpfs2_ssl binary that's mentioned in manpage httpfs2(1). Attempting to hardlink the httpfs2 binary into httpfs2_ssl to alter the argv0, similar to how it is commonly done with binaries such as busybox, does not modify the behavior, making me believe the HTTPS functionality is actually completely missing in this build, which severely limits the functionality of this package in 2023. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 httpfs2 depends on: ii libc6 2.36-7 ii libfuse2 2.9.9-6 Versions of packages httpfs2 recommends: ii fuse3 [fuse] 3.12.0-1 httpfs2 suggests no packages. -- no debconf information
Bug#1028424: type hint wrong in php-horde-imap-client
Package: php-horde-imap-client Version: 2.30.6-2 upgrading from 2.30.6-1 I get Return value of Horde_Imap_Client_Namespace_List::offsetGet() must be an instance of mixed, instance of Horde_Imap_Client_Data_Namespace returned removing mixed from /usr/share/php/Horde/Imap/Client/Namespace/List.php ar line 87 fix the problem -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1009698: marked as done (util-linux: more is less like more and more like less now :-))
>>>>> On 2023-01-07 12:37:03 +0100, Chris Hofstaedtler wrote: >>>>> Ivan Shmakov [230107 10:39]: […] >> My understanding is that the Debian BTS exists for the benefit >> of Debian users at large, not just the developers and maintainers; >> and in particular serves to inform the users of the issues they >> can run into upon upgrade. (And if that’s somehow not the case, >> I’d kindly suggest that an alternative BTS is created for that >> purpose.) > This is not my understanding of the Debian BTS. Indeed, if the bug > tracker produces a long list of "bugs" that are unactionable to me, > then it is not serving any useful purpose to me. > The end effect is one that can be seen for most high-usage packages: > actually relevant bugs are forgotten by the maintainers, put into > the same bucket as all the other, not-so-relevant entries > (not-really-"bugs"). The web interface lists wontfix bugs separately to other reports; see, e. g., http://bugs.debian.org/src:tightvnc . If you have suggestions on how that list can be improved, I’d be willing to look into the code (sometime within the next few months) and propose a patch. (I’m not familiar with any other Debian BTS UIs, so won’t be able to help with those, though.) > I want to stress that this report is not a "bug" at all: just > new, different behaviour. The change that Debian users have found problematic. […] > In this case, I specially love that for three quarters of a year > nothing has happened - after my suggestion of talking to upstream, > just silence. > Once I close the report, people show up with useful info and > also with opinions on how I should run the BTS for a package I > maintain. I don’t have vested interest in how more(1) behaves as I don’t use it myself. (Though I still help other users with it, as well as with a bunch of other Debian tools, from time to time.) That said, I’m still following the util-linux Debian BTS reports (somewhat loosely, admittedly), as, quite obviously, I /do/ rely on the package rather heavily. In this case, what provoked my response is specifically how Debian BTS is used, which is something I’m also invested in. We’re all volunteers here (and this also means that we can’t run the BTS like a corporation would IMO), so I can’t in any way ‘force’ my understanding on anyone, but I’d still think explaining my point from time to time would be of some value to the project. There wouldn’t be much improvement should we all keep our suggestions to ourselves, no? […] -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1009698: marked as done (util-linux: more is less like more and more like less now :-))
>>>>> Chris Hofstaedtler wrote: > Subject: no additional feedback > Closing for lack of anything actionable. JFTR, the workaround for this issue is to put -e either to the command line, or to the MORE environment variable’s value. It seems like in Bullseye, more(1) ignores unrecognized options, so that should work for ~/.profile (or any other file used to initialize user’s environment) shared across Debian releases. I believe that the correct course of action is not to close the report, as the problem still exists, is still reproducible, and still affects, or can affect, Debian users; but rather to downgrade to wishlist and tag as wontfix. At the very least, that would help avoid duplicate reports of this same issue. (As to actionability, I understand the unwillingness to deviate from upstream, but I’d argue that such a deviation /is/ nevertheless an ‘action’ that /can/ be performed by a maintainer.) My understanding is that the Debian BTS exists for the benefit of Debian users at large, not just the developers and maintainers; and in particular serves to inform the users of the issues they can run into upon upgrade. (And if that’s somehow not the case, I’d kindly suggest that an alternative BTS is created for that purpose.) TYC. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1027001: regression for return type hints
package: php-horde-mail version: 2.6.6-4 Hi, again I'm not sure if this is a regression or a bug since I run a local patched version of horde but after upgrading php-horde-mail:amd64 2.6.6-3 -> 2.6.6-4 I started to get errors related to hint return type. Downgrading didn't fix the problem. One was particularly insidious since I wasn't able to find anything in the log to point me to the culprit line... But it is in: Imap/Client/Tokenize.php 223 error says it should be string in spite of mixed, I just dropped the hint type since string sounded too generic and went to the successive error Return value of Horde_Imap_Client_Namespace_List::offsetGet() must be an instance of mixed, instance of Horde_Imap_Client_Data_Namespace returned ./Imap/Client/Namespace/List.php:public function offsetGet($offset): mixed 87 again I just dropped the hint and everything seems to work thanks and if you can happy holiday -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1026819: regression in DB?
Package: php-horde-db Version: 2.4.1-4 Upgrading from 2.4.1-3 got me A fatal error has occurred Return value of Horde_Db_Adapter_Base_Result::current() must be an instance of mixed, array returned in /usr/share/php/Horde/Db/Adapter/Base/Result.php:136 Since I run a manually patched version and I've lost track of the patches that reached upstream I can't say if it is a regression or a previously unoticed problem or something I forgot to report but line 131 of /usr/share/php/Horde/Db/Adapter/Base/Result.php should be public function current(): array thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1025769: HTTP::Server::Simple vs. support for Unix domain sockets
>>>>> On 2022-12-09 02:11:07 +0100, gregor herrmann wrote: >>>>> On Thu, 08 Dec 2022 20:07:38 +, Ivan Shmakov wrote: >> Attempting to implement Unix domain socket support by subclassing >> HTTP::Server::Simple uncovered several issues with the latter, >> which I’m going to describe in this report. (Feel free to clone >> it and address them separately as you see fit.) > Thanks for your bug report. > I’m afraid to say that it mostly is not actionable from the > Debian packaging side. What you propose, in my understanding, > are massive changes to the code, and that’s not what we are > going to do on our own in Debian, but something which needs > to be discussed with upstream and needs to happen there. Not all of the changes I propose are what I’d call ‘massive.’ To summarize: (peer_identify): New method, split off (_process_request): this one. Fixed: only call sockaddr_in on the remote address if its family is AF_INET (was: whenever the family is not AF_INET6.) (listener_handle): New method, allowing for per-instance listener sockets (was: using a single HTTPDaemon filehandle.) (restart): Fixed: supply $^X as an indirect object to exec if $0 is not executable (was: using $0 unconditionally.) (setup): Fixed: use (same as above) for peeraddr example value (was: suggesting that peername can be a hostname while peeraddr cannot.) Mention explicitly in the prose that both peername and peeraddr are currently the same string value representing the remote IPv6 or IPv4 address, and that the code never attempts (potentially time-consuming) reverse DNS calls. Of the above, the first change is the most important for my use case, and even if implemented only partially: (_process_request): Fixed: only call sockaddr_in on the remote address if its family is AF_INET (was: whenever the family is not AF_INET6.) it would still be helpful. The second change is the most invasive. And the rest seem straightforward bugfixes, with the exec one being one-liner. > I can forward your ideas upstream I’d appreciate that. > but it might be easier if you do it yourself as this will > potentially require discussion: > https://github.com/bestpractical/http-server-simple I have no Github account (and I’d rather keep it that way.) I have a CPAN account, though, so I can report the issues to the CPAN RT instance [1], if the upstream monitor that. [1] http://rt.cpan.org/Public/Dist/Display.html?Name=HTTP-Server-Simple >> So far as I can tell, it’s perfectly possible to subclass and >> use HTTP::Server::Simple without libcgi-pm-perl, except perhaps >> with Net::Server (I’m not familiar with the latter and won’t >> claim understanding of what the run method does in the case >> net_server is supplied.) >> The Recommends: relation seems like a better fit in this case: > That’s something relevant for packaging; but I’m not so sure about > your conclusion. After looking around a bit I think I can say > that lib/HTTP/Server/Simple/CGI.pm needs CGI.pm; libcgi-pm-perl > needs to be in Build-Depends-Indep, otherwise the tests fails > (which was not your point); moving libcgi-pm-perl from Depends to > Recommends does not break autopkgtests so it would be ok at first > sight, the question is if we want to ensure an always working > HTTP::Server::Simple::CGI. In the end I guess a Recommends would > be arguable but it’s not that clear-cut IMO … IME it rarely is. The caveat here is that all the packages that depend on libhttp-server-simple-perl /and/ use HTTP::Server::Simple::CGI would need to be updated to depend on libcgi-pm-perl as well. Another alternative is to put HTTP::Server::Simple::CGI into its own binary package, with the dependencies declared as follows: Package: libhttp-server-simple-perl Depends: perl:any Recommends: libhttp-server-simple-cgi-perl Package: libhttp-server-simple-cgi-perl Depends: libcgi-pm-perl, libhttp-server-simple-perl It doesn’t avoid the need to check and possibly update all of the depending packages, though. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1025769: HTTP::Server::Simple vs. support for Unix domain sockets
Package: libhttp-server-simple-perl
Version: 0.52-2
Severity: minor
[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]
In true multiuser setups, it’s much easier to control access
to Unix domain sockets than to INET6 and INET ones: for the
first, chmod(1) and chacl(1) can be used, while the second
is likely to require configuring nftables or iptables as root.
Attempting to implement Unix domain socket support by
subclassing HTTP::Server::Simple uncovered several issues
with the latter, which I’m going to describe in this report.
(Feel free to clone it and address them separately as you
see fit.)
As an aside, note that both Apache mod_proxy (as of 2.4.7)
and Lighttpd mod_proxy provide support for passing HTTP
traffic to a Unix domain socket; consider, e. g.:
## Lighttpd
$HTTP["url"] =~ "^/(example)(/|$)" {
proxy.server = ("" => (("host" => "/where/is/%1.socket")))
}
## From http://httpd.apache.org/docs/2.4/mod/mod_proxy.html
# Unix sockets require 2.4.7 or later
SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/"
Making HTTP requests via a Unix socket is supported by
curl(1) as well, e. g.:
$ curl --unix-socket ~/my.server.socket http://-/foo
The first issue is that while most of the HTTP::Server::Simple
functionality is implemented as separate methods, easy to
override in a subclass, calls to sockaddr_in6 and sockaddr_in
are hardcoded into _process_request:
421 my $remote_sockaddr = getpeername( $self->stdio_handle );
422 my $family = sockaddr_family($remote_sockaddr);
423
424 my ( $iport, $iaddr ) = $remote_sockaddr
425 ? ( ($family == AF_INET6) ?
sockaddr_in6($remote_sockaddr)
426 :
sockaddr_in($remote_sockaddr) )
427 : (undef,undef);
I believe that this code should be split off into a separate
method (or at least the sockaddr_in call should be explicitly
guarded as sockaddr_in6 already is), like:
sub peer_identify
{
my ($self, $peer) = @_;
my $remote_sockaddr = getpeername( $self->stdio_handle );
my $family = sockaddr_family($remote_sockaddr);
my ( $iport, $iaddr )
= ( ($family == AF_INET6) ? sockaddr_in6 ($remote_sockaddr)
($family == AF_INET) ? sockaddr_in ($remote_sockaddr)
: (undef, undef) );
...
return ("peername" => ..., "peeraddr" => ..., "peerport" => ...);
}
This is critical to my UNIX subclass [1], as the (currently
unguarded) call to sockaddr_in on a Unix name results in an
exception, which I worked-around by overriding
Socket::unpack_sockaddr_in with a function that returns undef
if the original function throws an exception on the value
passed while unpack_sockaddr_un doesn’t (see [1].)
[1] http://am-1.org/~ivan/src/iroca-2022/lib/HTTP/Server/Simple/UNIX.pm
[2] http://am-1.org/~ivan/src/iroca-2022/test/53-un-serv.perl
Another issue is that the documentation suggests that
peername and peeraddr may be different values (presumably
the former would be an IP resolved into a hostname via rDNS,
while the latter is the address in the numeric form):
563 ITEM/METHOD Set toExample
…
570 port Received Port 80, 8080
571 peername Remote name "200.2.4.5", "foo.com"
572 peeraddr Remote address"200.2.4.5", "::1"
573 peerport Remote port 42424
574 localnameLocal interface "localhost", "myhost.com"
This is not the case the way _process_request is currently
implemented:
447 my ( $file, $query_string )
448 = ( $request_uri =~ /([^?]*)(?:\?(.*))?/s );# split at ?
449
450 $self->setup(
…
458 peername => $peeraddr,
459 peeraddr => $peeraddr,
460 peerport => $iport,
461 );
And before that, $peeraddr is obtained from Socket::getnameinfo:
429 my $loopback = ($family == AF_INET6) ? "::1" : "127.0.0.1";
430 my $peeraddr = $loopback;
431 if ($iaddr) {
432 my ($host_err,$addr, undef) =
Socket::getnameinfo($remote_sockaddr,Socket::NI_NUMERICHOST);
433 warn ($host_err) if $host_err;
434 $peeraddr = $addr || $loopback;
435 }
AIUI, the end
Bug#1025751: manpages.d.o pages have json-ld objects double-encoded as strings
Package: manpages.debian.org
Severity: minor
[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
While I’m not sure if it perhaps /is/ an accepted practice,
I’d venture to guess that the way manpages.debian.org encodes
JSON-LD objects as strings /and then/ encodes the resulting
strings as JSON strings /yet again,/ is going to confuse some
of the processing tools out there.
Consider, e. g. (split for readability):
"{\"@context\":\"<a rel="nofollow" href="http://schema.org\",\"@type\":\"BreadcrumbList\"">http://schema.org\",\"@type\":\"BreadcrumbList\"</a>;,
\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,
\"item\":{\"@type\":\"Thing\",\"@id\":\"/contents-unstable.html\",
\"name\":\"unstable\"}},{\"@type\":\"ListItem\",\"position\":2,
\"item\":{\"@type\":\"Thing\",\"@id\":\"/unstable/acl/index.html\",
\"name\":\"acl\"}},{\"@type\":\"ListItem\",\"position\":3,
\"item\":{\"@type\":\"Thing\",\"@id\":\"\",\"name\":\"getfacl(1)\"}}]}"
— https://manpages.debian.org/unstable/acl/getfacl.1.en.html
Versus, say, https://en.wikipedia.org/wiki/JSON-LD (which
I presume is the correct usage):
{"@context":"https:\/\/schema.org","@type":"Article","name":"JSON-LD",
"url":"https:\/\/en.wikipedia.org\/wiki\/JSON-LD",
"sameAs":"http:\/\/www.wikidata.org\/entity\/Q6108942",
"mainEntity":"http:\/\/www.wikidata.org\/entity\/Q6108942",
"author":{"@type":"Organization",
"name":"Contributors to Wikimedia projects"},
"publisher":{"@type":"Organization","name":"Wikimedia Foundation, Inc.",
"logo":{"@type":"ImageObject",
"url":"https:\/\/www.wikimedia.org\/static\/images\/wmf-hor-googpub.png"}},
"datePublished":"2011-12-30T17:43:17Z",
"dateModified":"2022-11-15T22:34:49Z",
"headline":"a method of encoding Linked Data using JSON"}
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#1025091: toot: Posting toots with media attachment fails
On Tue, 29 Nov 2022, at 19:27, gregor herrmann wrote: > As far as I can guess from the debug output, toot expects something > in text_url the but reply from the server contains "text_url":null The text_url field was deprecated and seems to be removed in Mastodon 4. This bug is fixed in toot 0.30.1. Regards, -- Ivan
Bug#1024687: libfm-qt11:amd64 1.1.0-3 -> 1.2.0-1 breaks some lxqt functionalities
Package: libfm-qt11 Version: 1.2.0-1 After upgrading libfm-qt11 desktop restart with this error in a popup window: Crash Report Desktop crashed too many times. Its autorestart has been disabled until next login. lxqt configuration center -> Desktop can't be run anymore. Downgrading fix the problem. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1024099: tootle: Segfault when clicking on images
Package: tootle Version: 1.0-alpha2-1 Severity: normal X-Debbugs-Cc: northivanas...@gmail.com Dear Maintainer, I've installed Tootle on a Debian 11 system running GNOME 3.38 from the Debian package. I logged in to my (newly created) account and clicked on an image in a post on my feed, expecting to see the full image (apparently the intended behavior is to download the image and open it in an external app). Instead, the app hung for a few seconds and then crashed. The terminal output shows the package segfaulted. This issue doesn't seem to impact the package from flathub, so I assume this is an issue with the older alpha version of Tootle shipped in Debian, or with the Debian package. I've yet to check if this affects Bookworm's 1.0-ds1-4. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tootle depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii elementary-xfce-icon-theme 0.15.2-1 ii libc62.31-13+deb11u5 ii libcairo21.16.0-5 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libgee-0.8-2 0.20.4-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libhandy-1-0 1.0.3-2 ii libjson-glib-1.0-0 1.6.2-1 ii libsoup2.4-1 2.72.0-2 tootle recommends no packages. tootle suggests no packages.
Bug#1022851: xorriso: -clone across sessions copies, not clones
Package: xorriso Version: 1.5.4-4 Control: found -1 1.5.0-1 Control: found -1 1.5.2-1 When -clone is used on a file that belongs to the loaded session, its contents get /copied/ to the new one (with the location of the original one updated to match the copy); while when used on a file /within/ the current session, the resulting file (as expected) appears to share the extent with the original one. I believe that when it comes to rearranging data on ECMA 119 filesystems, it is as important for -clone /not/ to copy the affected files’ contents as it is for, say, -move. Consider, for instance, the following shell code. #!/bin/sh set -e set -x set -C -u ## NB: an arbitrary value, but must be larger than first session size session_offset=256 f=$(mktemp -- /tmp/hello.X) printf %s\\n "Hello, world!" >| "$f" g=$(mktemp -- /tmp/iso.X) xorriso -padding 0 -uid 0 -gid 0 \ -outdev stdio:/dev/fd/5 5>| "$g" \ -pathspecs on -add /hello/hello.world="$f" -- \ -clone /hello/hello.world /hello/hello.withn h=$(mktemp -- /tmp/iso.X) xorriso -padding 0 -uid 0 -gid 0 \ -indev stdio:/dev/fd/4 4< "$g" \ -grow-blindly "$session_offset" \ -outdev stdio:/dev/fd/5 5>| "$h" \ -clone /hello/hello.world /hello/hello.clone dd bs=2048 seek="$session_offset" conv=notrunc of="$g" < "$h" isoinfo -l -i /dev/stdin < "$g" isoinfo -l -T "$session_offset" -i /dev/stdin < "$g" The resulting sessions are as follows. + isoinfo -l -i /dev/stdin Directory listing of / d- 0002048 Oct 26 2022 [ 18 02] . d- 0002048 Oct 26 2022 [ 18 02] .. d- 0002048 Oct 26 2022 [ 20 02] HELLO Directory listing of /HELLO/ d- 0002048 Oct 26 2022 [ 20 02] . d- 0002048 Oct 26 2022 [ 18 02] .. -- 000 14 Oct 26 2022 [ 33 00] HELLO.WITHN;1 -- 000 14 Oct 26 2022 [ 33 00] HELLO.WORLD;1 + isoinfo -l -T 256 -i /dev/stdin Directory listing of / d- 0002048 Oct 26 2022 [274 02] . d- 0002048 Oct 26 2022 [274 02] .. d- 0002048 Oct 26 2022 [276 02] HELLO Directory listing of /HELLO/ d- 0002048 Oct 26 2022 [276 02] . d- 0002048 Oct 26 2022 [274 02] .. -- 000 14 Oct 26 2022 [280 00] HELLO.CLONE;1 -- 000 14 Oct 26 2022 [280 00] HELLO.WITHN;1 -- 000 14 Oct 26 2022 [280 00] HELLO.WORLD;1 Note that all three entries moved from LBA 33 to LBA 280. Using two months old versions from Git (libburn 19545142, libisoburn 3318fa47 and libisofs c6cb7dfa; the few changes since these revisions made to the latter two don’t seem to be relevant to the issue) gives the same result. Omitting the -grow-blindly option (and using -dev stdio:"$h" instead) doesn’t seem to change this behavior, either. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1021974: adding dkms log
Just adding dkms make log. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net DKMS make.log for nvidia-tesla-470-470.141.03 for kernel 6.0.0-1-amd64 (x86_64) Fri Oct 21 06:07:39 PM CEST 2022 make KBUILD_OUTPUT=/lib/modules/6.0.0-1-amd64/build V=1 -C /lib/modules/6.0.0-1-amd64/source M=/var/lib/dkms/nvidia-tesla-470/470.141.03/build ARCH=x86_64 NV_KERNEL_SOURCES=/lib/modules/6.0.0-1-amd64/source NV_KERNEL_OUTPUT=/lib/modules/6.0.0-1-amd64/build NV_KERNEL_MODULES="nvidia nvidia-uvm nvidia-modeset nvidia-drm nvidia-peermem" INSTALL_MOD_DIR=kernel/drivers/video NV_SPECTRE_V2=0 modules make[1]: Entering directory '/usr/src/linux-headers-6.0.0-1-common' make -C /usr/src/linux-headers-6.0.0-1-amd64 -f /usr/src/linux-headers-6.0.0-1-common/Makefile modules make[2]: Entering directory '/usr/src/linux-headers-6.0.0-1-amd64' test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) make -f /usr/src/linux-headers-6.0.0-1-common/scripts/Makefile.build obj=/var/lib/dkms/nvidia-tesla-470/470.141.03/build \ single-build= \ need-builtin=1 need-modorder=1 NV_CONFTEST_CMD=/bin/sh /var/lib/dkms/nvidia-tesla-470/470.141.03/build/conftest.sh " gcc-12" x86_64 /lib/modules/6.0.0-1-amd64/source /lib/modules/6.0.0-1-amd64/build NV_CONFTEST_CFLAGS=-O2 -D__KERNEL__ -DKBUILD_BASENAME="#conftest43911" -DKBUILD_MODNAME="#conftest43911" -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/12/include -I/lib/modules/6.0.0-1-amd64/source/arch/x86/include/asm/mach-default -I/lib/modules/6.0.0-1-amd64/source/include/asm-x86/mach-default -I/lib/modules/6.0.0-1-amd64/build/include2 -I/lib/modules/6.0.0-1-amd64/build/include -include /lib/modules/6.0.0-1-amd64/build/include/generated/autoconf.h -I/lib/modules/6.0.0-1-amd64/source/arch/x86/include -I/lib/modules/6.0.0-1-amd64/source/arch/x86/include/uapi -I/lib/modules/6.0.0-1-amd64/build/arch/x86/include/generated -I/lib/modules/6.0.0-1-amd64/build/arch/x86/include/generated/uapi -I/lib/modules/6.0.0-1-amd64/source/include -I/lib/modules/6.0.0-1-amd64/source/include/uapi -I/lib/modules/6.0.0-1-amd64/source/include/xen -I/lib/modules/6.0.0-1-amd64/build/include/generated/uapi -mfentry -DCC_USING_FENTRY -I/var/lib/dkms/nvidia-tesla-470/470.141.03/build/common/inc -I/var/lib/dkms/nvidia-tesla-470/470.141.03/build -Wall -MD -Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"470.141.03\" -Wno-unused-function -Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0 -DNV_KERNEL_INTERFACE_LAYER -fno-pie -Wall -Wundef -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-array-bounds -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check -fconserve-stack -Wno-packed-not-aligned -g KBUILD_CFLAGS=-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address -Wno-fo
Bug#1021974: nvidia-tesla-470-driver stopped to work with kernel 6.0
Package: nvidia-tesla-470-driver Version: 470.141.03-2 probably this? https://forums.developer.nvidia.com/t/470xx-drivers-and-linux-6-0-kernel/229735 thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1020784: wrong return type in PHP
Package: php-horde-db Version: 2.4.1-3 This slipped in upgrading from 2.4.1-1 to 2.4.1-3 probably as part of an attempt to make horde more testable/php8 ready[*] A fatal error has occurred Return value of Horde_Db_Adapter_Base_Result::current() must be an instance of mixed, array returned in /usr/share/php/Horde/Db/Adapter/Base/Result.php:136 public function current(): mixed should be public function current(): array running on php 7.4.30 [*] sorry sorry... I didn't actually do any work other than setting up a remote xdebug environment... -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1018105: crashes as soon as adding text, keyboard don't input text rather seems to trigger "shortcuts"
f8c954e9a98 in g_signal_emit_by_name () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #33 0x7f8c95f1f030 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #34 0x7f8c95f1f613 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #35 0x7f8c5a2e696b in ?? () from /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so No symbol table info available. #36 0x55f81f426a48 in gimp_text_tool_editor_key_press () No symbol table info available. #37 0x55f81f47c1cc in ?? () No symbol table info available. #38 0x55f81f47d139 in gimp_display_shell_canvas_tool_events () No symbol table info available. #39 0x7f8c95f391ab in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #40 0x7f8c954cf500 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #41 0x7f8c954e2b36 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #42 0x7f8c954e8eed in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #43 0x7f8c954e987f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #44 0x7f8c96058fe4 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #45 0x7f8c9606d248 in gtk_window_propagate_key_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #46 0x55f81f59723a in ?? () No symbol table info available. #47 0x7f8c95f391ab in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #48 0x7f8c954cf500 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #49 0x7f8c954e2c65 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #50 0x7f8c954e8eed in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #51 0x7f8c954e987f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #52 0x7f8c96058fe4 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #53 0x7f8c95f3787c in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #54 0x7f8c95f37c4b in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #55 0x7f8c963e8afc in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 No symbol table info available. #56 0x7f8c953d5729 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #57 0x7f8c953d59b8 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #58 0x7f8c953d5c6f in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #59 0x55f81f3704e1 in app_run () No symbol table info available. #60 0x55f81f36fddf in main () No symbol table info available. [Inferior 1 (process 5458) detached] ``` -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1018760: i915: "Failed to get the SoC PWM chip", unable to adjust backlight on x7-Z8750 / GPD Pocket 1
Package: src:linux Version: 5.10.136-1 Severity: normal X-Debbugs-Cc: krylov.r...@gmail.com Dear Maintainer, On my GPD Pocket 1, the backlight worked well with the 4.19 kernel from stretch-backports. After the upgrade to Bullseye, I cannot adjust the backlight intensity either using the keyboard shortcuts or by writing into /sys/class/backlight/acpi_video0/brightness. In the latter case, the write succeeds but doesn't have an effect on my display. I can also see this problem with the 5.18 kernel from bullseye-backports. The following lines from the kernel log seem to be relevant, but I'm afraid I'm completely at a loss regarding what can be done to fix the problem: [ +0,009771] i915 :00:02.0: [drm] *ERROR* Failed to get the SoC PWM chip [ +0,006728] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 I do have VirtualBox installed from Debian Fasttrack, which does taint the kernel, but the problem has been present even before I installed the package. Please let me know if there's anything else I can do to help. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Default string product_name: Default string product_version: Default string chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: 5.11 board_vendor: AMI Corporation board_name: Default string board_version: Default string ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register [8086:2280] (rev 34) Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register [8086:7270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:0b.0 Signal processing controller [1180]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller [8086:22dc] (rev 34) Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller [8086:7270] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device_pci_legacy 00:14.0 USB controller [0c03]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5] (rev 34) (prog-if 30 [XHCI]) Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:7270] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:1a.0 Encryption controller [1080]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine [8086:2298] (rev 34) Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine [8086:7270] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_txe Kernel modules: mei_txe 00:1c.0 PCI bridge [0604]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1 [8086:22c8] (rev 34) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1f.0 ISA bridge [0601]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU [8086:229c] (rev 34) Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU [8086:7270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: lpc_ich Kernel modules: lpc_ich 01:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4356 802.11ac Wireless Network Adapter [14e4:43ec] (rev 02) Subsystem: Gemtek Technology Co., Ltd BCM4356 802.11ac Wireless Network Adapter [17f9:0036]
Bug#1016653: gm(1): improve targa (.tga) orientation bits support
Control: retitle -1 gm(1): improve targa (.tga) orientation bits support >>>>> Bob Friesenhahn writes: > However, I believe that this bug report is incorrect. After reading [1] (and trying both ImageMagick and GraphicsMagick on the samples*/ provided therein), I guess my suggestions would be as follows. 1. GraphicsMagick .tga reader should support all the combinations of the orientation bits, not just the default ‘bottom left’; (I gather that’s something already in Git?) 2. It should be possible to specify orientation explicitly both when reading .tga files (my understanding is that files produced by buggy .tga writers that get these wrong are not uncommon in the wild) and when writing them (for the benefit of legacy readers that only implement a specific orientation; a quick look into LDPCXTGA’s ldtga.cpp has confirmed that it ignores all the .tga metadata but width and height fields and assumes the non-default TopLeft orientation.) I haven’t checked the source, but it seems that at least -orient is ignored by the GraphicsMagick .tga writer. 3. I’d think the documentation should feature -auto-orient more prominently in the examples. (I’ve retitled the bug report accordingly.) TYC. [1] http://gitlab.com/illwieckz/produce-reference-tga > What has actually happened is that ImageMagick changed what it > returns and more recent ImageMagick also changed what it does > when it displays an image. It sounds like the behavior of ImageMagick’s display(1) was reversed exactly twice, which should’ve resulted in the original behavior being restored, at least so long as the user is concerned. What am I missing here? > GraphicsMagick always returns an image in the common normal form > (TopLeft). ImageMagick changed so that it returns an image in > the same form as the file, but it sets an orientation option so > that the user needs to use -auto-orient to see a correct image. Seems to be the case for .tga images, indeed. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1018240: Xtightvnc(1): support arbitrary stdio in -inetd, not just socket-based
ion invariably leads to the termination of the associated X session. (While with the VNC server possessing a listening socket, which is the default case, and also would’ve been one were Xtightvnc(1) to support ‘wait’ inetd.conf(5) option, it’s possible to reconnect.) IME in LAN environments, it’s an acceptable tradeoff. Ideally, this should be complemented by a -command option in xvncviewer(1), to access the remote server by starting the command given in place of opening a TCP connection directly (not unlike ssh_config(5) ProxyCommand option.) But that deserves a separate report IMO. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1018239: live-boot: please add support for subroot= option
Package: live-boot
Version: 1:20220505
Severity: wishlist
Tags: patch
Control: found -1 1:20190614
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
SquashFS support for file-level deduplication makes it more
space-efficient to have several distinct Debian installs on
a single SquashFS image, rather than have one image per
install (as per the following syslinux.cfg example snippet.)
LABEL bookworm-2022-08-20
...
APPEND ... boot=live toram=6300e90c.squashfs ...
LABEL bookworm-2022-08-24
...
APPEND ... boot=live toram=6305aa79.squashfs ...
This in turn can be used for tracking testing / unstable,
or for having an image with conflicting packages installed
(even though only one of any given set of such will be
usable for a given boot.)
Moreover, this allows for the SquashFS in question to be
updated incrementally, rather than written anew each time,
which is more friendly to flash-based storage devices; and
also allows for booting into an earlier install should there
be issues with the latest one.
I hereby suggest that a subroot= option is implemented, to
point to a subdirectory on the underlying read-only image to
be used in place of its root; like, Syslinux-wise:
LABEL bookworm-2022-08-24
...
APPEND ... boot=live toram=bookworm.squashfs subroot=x6305aa79 ...
The overlay will then use lowerdir=/run/live/rootfs/bookworm
.squashfs/x6305aa79 in place of /run/live/rootfs/bookworm
.squashfs .
FWIW, I’m using this feature for all my ‘live’ images for
a couple of years now, but my configurations are somewhat
similar, so I can’t claim that I’ve tested it extensively.
Also, while we’re at it, I’ve followed the surrounding
code’s style and used:
subroot=*) ROOTINFIX="${_PARAMETER#subroot=}" ...
union=*) UNIONTYPE="${_PARAMETER#union=}" ...
But it sure is less redundant (and thus less error-prone)
to use instead:
subroot=*) ROOTINFIX="${_PARAMETER#*=}" ...
union=*) UNIONTYPE="${_PARAMETER#*=}" ...
Note that in the latter case there’s only one place the
option name needs to be changed (or aliases added), if
ever need arises.
--
FSF associate member #7257 http://am-1.org/~ivan/
--- lib/live/boot/.9990-overlay.sh.~2022-08-23~ 2022-05-05 10:16:56 +
+++ lib/live/boot/9990-overlay.sh 2022-08-23 22:45:09 +
@@ -83,7 +83,7 @@ setup_unionfs ()
if [ -d "${image}" ]
then
# it is a plain directory: do nothing
-rootfslist="${image} ${rootfslist}"
+rootfslist="${image}${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
elif [ -f "${image}" ]
then
if losetup --help 2>&1 | grep -q -- "-r\b"
@@ -106,7 +106,7 @@ setup_unionfs ()
esac
mpoint=$(trim_path "${croot}/${imagename}")
-rootfslist="${mpoint} ${rootfslist}"
+rootfslist="${mpoint}${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
mount_options=""
# Setup dm-verity support if a device has it supported
@@ -188,9 +188,9 @@ setup_unionfs ()
log_begin_msg "Mounting \"${image_directory}\" on \"${croot}/filesystem\""
mount -t $(get_fstype "${image_directory}") -o ro,noatime "${image_directory}" "${croot}/filesystem" || \
panic "Can not mount ${image_directory} on ${croot}/filesystem" && \
- rootfslist="${croot}/filesystem ${rootfslist}"
+ rootfslist="${croot}/filesystem${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
# probably broken:
- mount -o bind ${croot}/filesystem $mountpoint
+ mount -o bind "${croot}/filesystem${ROOTINFIX:+/$ROOTINFIX}" "$mountpoint"
log_end_msg
fi
--- lib/live/boot/.9990-cmdline-old.~2022-08-23~ 2022-05-05 10:16:56 +
+++ lib/live/boot/9990-cmdline-old 2022-08-23 22:45:10 +
@@ -257,6 +257,11 @@ Cmdline_old ()
export ROOT
;;
+ subroot=*)
+ROOTINFIX="${_PARAMETER#subroot=}"
+export ROOTINFIX
+;;
+
union=*)
UNIONTYPE="${_PARAMETER#union=}"
export UNIONTYPE
Bug#1018238: gm(1): please add Linux framebuffer (/dev/fb0) support
Package: graphicsmagick
Version: 1.4+really1.3.38-1
Severity: wishlist
Control: found -1 1.4+really1.3.36+hg16481-2
Control: found -1 1.4+really1.3.35-1~deb10u2
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
It is currently possible to use $ gm convert command to show
images by writing them directly into Linux framebuffer, provided
that the /dev/fb0 device file permissions are set appropriately.
For instance, on my system, the command could be:
$ gm convert -resize 1280x1024 -gravity center -extent 1280x1024 \
-depth 8 -recolor "0 0 1 0, 0 1 0 0, 1 0 0 0, 0 0 0 1" \
IMAGEFILE\[0] rgba:/dev/fb0
Similarly, it’s possible to take screenshots, though the
only way to do so that I was able to figure out requires
a simple byte order conversion helper, like:
$ (perl -e 'use common::sense; binmode (STDIN); binmode (STDOUT);
local $/ = \(4 * 1280); while () {
s/(.)(.)(.)./$3$2$1\377/g; print ($_); }' \
< /dev/fb0 \
| gm convert -size 1280x1024 -depth 8 rgba:- SCREENSHOT.png)
The obvious inconvenience here is that the framebuffer data
format (-size, -depth, but in general also the layout and
such things as the use of indexed color instead of RGB(A))
vary from system to system, depending on the hardware and
its boot- (e. g., I use video=VGA-1:1280x1024-24 on my system)
and run-time (as could be set with fbset(1), at least on
some arm64 machines) configuration.
I therefore suggest that a new ‘Linux framebuffer’ image
format is implemented in GraphicsMagick that would use the
FBIOGET_FSCREENINFO ioctl [1] to figure out the framebuffer
resolution and format before reading (writing) image data
from (to) it; like:
$ gm convert imagefile linuxfb:/dev/fb0
$ gm convert linuxfb:/dev/fb0 screenshot.png
$
[1] http://kernel.org/doc/html/latest/fb/api.html
Better still if it’d be possible to select a portion of
framebuffer for reading (without reading the whole framebuffer
first), or to put the image into a given position on screen
when writing. While this won’t turn gm(1) into a fully-featured
framebuffer image viewer, for what we have fbi(1) already,
arguably it would be rather a convenient feature to use from
scripts.
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#956506: Confirmed, regression since 5:102 in buster
Confirming I'm also seeing this bug after an upgrade of my desktop to bullseye. It worked fine in buster (kde-plasma-desktop 5:102), though I freely confess I have no idea which underlying KDE component or package is invovled. Looks like this is upstream bug #413104 - I confirmed the bug is only present when using "Desktop" layout, not "Folder View". -- Ivan Kohler
Bug#1016657: enable ipv6 and math options (and more?); harmonize README.*
Source: jimtcl
Version: 0.81+dfsg0-2
Severity: minor
Control: found -1 0.77+dfsg0-3
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
[Using Severity: minor chiefly due to the inclusion of the
README.* discrepancy in this report; feel free to clone and
address the issues separately.]
It’s customary for packages to be built for Debian with all
possible options enabled; or, alternatively, for there to be
separate ‘fully-featured’ and ‘low-footprint’ packages (such
as vim-nox vs. vim vs. vim-tiny; or exim4-daemon-heavy vs.
exim4-daemon-light; etc.)
Assuming there’d be no negative implications for Jim users
in Debian (such as openocd) in doing so, I request that ipv6
and math options are enabled for Debian Jim packages; which,
I presume, could be achieved by adding --ipv6 and --math to
the second dh_auto_configure invocation in debian/rules:
24
25 override_dh_auto_configure: autosetup/jimsh0.c
26 dh_auto_configure --builddirectory=static/
27 dh_auto_configure -- --shared
28
Currently both options are evidently disabled:
$ jimsh -e "socket -ipv6 stream.server "
ipv6 not supported
$ jimsh -e "expr { sin (1) } "
syntax error in expression: " sin (1) "
$
It’d be nice to have UTF-8 support enabled as well (--utf8),
but I’m less certain that it won’t interfere with current Jim
users in Debian.
$ jimsh -e 'string length "\u2012" '
3
$ tclsh8.6 <(printf %s\\n 'puts [ string length "\u2012" ] ')
1
$
Overall, I’d think that /also/ having Jim packages built with
the --full configure option (which is to say, with support
for sqlite3, zlib and others) could come handy to some of us.
So far as I can tell, it’d involve making separate jimsh-full,
libjim-full and libjim-full-dev packages, which seems somewhat
unreasonable.
That, however, reminds me that there’s currently a discrepancy
between the README.* files installed by the package and the
features actually enabled at build time. Namely, the jimsh
package includes the README.sqlite.gz and README.utf-8.gz
files, which correspond to features that are disabled and
unavailable to Debian jimsh package users. Conversely, the
package /does not/ include README.namespaces, despite the
respective feature being enabled (by default.) Hence I also
request that this discrepancy be rectified.
TIA.
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#1016656: colcrt(1) produces broken (off-by-one?) output
Package: bsdextrautils Version: 2.38-4 Severity: minor Control: found -1 2.36.1-8+deb11u1 [Please do not Cc: me, for I’m “on the list,” so to say, and I try to reserve my inbox for private communication only. I’d have set up Mail-Followup-To:, but there doesn’t seem to be a way to make it point to the report being filed.] The colcrt(1) version from bsdextrautils produces output that does match neither the version from Debian Buster (bsdmainutils) nor, say, the version from NetBSD. Expected behavior (Buster, NetBSD 9; GNU Sed): $ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt Hello - Hello $ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt - Hello Hello $ Observed behavior: $ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt H e l l o - - - - - HHeeoo $ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt - H e l l o HHeeoo $ As a workaround, $ ul -t dumb can be used in place of $ colcrt -: $ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" \ | ul -t dumb Hello Hello $ -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1016653: gm(1): targa (.tga) files are read and written upside-down
Package: graphicsmagick Version: 1.4+really1.3.38-1 Severity: minor Control: found -1 1.4+really1.3.36+hg16481-2 Control: found -1 1.4+really1.3.35-1~deb10u2 [Please do not Cc: me, for I’m “on the list,” so to say, and I try to reserve my inbox for private communication only. I’d have set up Mail-Followup-To:, but there doesn’t seem to be a way to make it point to the report being filed.] While graphicsmagick claims to support ‘Truevision Targa’ format, its implementation is apparently slightly defective in that the images are read and written with their vertical axis reversed. Consider, for instance, SHAPES.TGA from [1]: it’s shown with the gray (#9c9c9c) ‘floor’ at the bottom of the image by both LDPCXTGA.EXE and ImageMagick’s display(1), yet $ gm display SHAPES.TGA shows the floor at the /top/ of the image instead. [1] http://archive.org/download/simtelnet_bu_mirror_2013_04 /simtelnet.bu.mirror.2013.04.zip/simtelnet%2Fmsdos%2Fgraphics %2Fldpcxtga.zip (URI split for readability.) The same applies to images produced with $ gm convert. The obvious workaround is to use -flip, like: $ gm display -flip SHAPES.TGA $ gm convert input.file -flip output.tga -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1014847: mirror submission for fastmirror.pp.ua
There are no restrictions on using the 6to4 tunnel at https://www.debian.org/mirror/ftpmirror. If it is forbidden to use 6to4 - let it be added to this site. If this is not the case, all other requirements have been met. If you see unfulfilled requirements - write about it. > 15 лип. 2022 р. о 00:32 Marco d'Itri написав(ла): > > On Jul 14, Ivan Barabash wrote: > >> That's true. My ISP doesn't have an IPv6 option. Also mirror speed and >> availability are not affected by the 6to4 tunnel. > Of course they are, since traffic will be routed to Warsaw and back. > If you cannot provide real IPv6 connectivity then just don't: this is > not 2002 anymore. > > -- > ciao, > Marco
Bug#1014847: mirror submission for fastmirror.pp.ua
On Wed, 13 Jul 2022 09:08:16 +0200 Marco d'Itri wrote: > On Jul 13, Ivan Barabash wrote: > > > Site: fastmirror.pp.ua > I do not think that it is appropriate to list a mirror which has IPv6 > connectivity from a tunnel broker. > > -- > ciao, > Marco That's true. My ISP doesn't have an IPv6 option. Also mirror speed and availability are not affected by the 6to4 tunnel.
Bug#1014847: mirror submission for fastmirror.pp.ua
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: fastmirror.pp.ua Type: leaf Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Ivan Barabash Country: UA Ukraine Location: Ukraine, Kyiv Trace Url: http://fastmirror.pp.ua/debian/project/trace/ Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua
Bug#1014731: php error after upgrading from 2.6.5-5 -> 2.6.6-1
Package: php-horde-mail Version: 2.6.6-1 After upgrading I get Return value of Horde_Mail_Rfc822_List::current() must be an instance of mixed, instance of Horde_Mail_Rfc822_Address returned downgrading solves the problem. May I also ask why php-horde-turba is stuck in unstable? thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1010098: xorriso: please allow -cut-out directly from block devices
>>>>> On 2022-04-26, Thomas Schmitt wrote:
>>>>> TS == Thomas Schmitt wrote:
TS> So if we exclude S_IFSOCK, S_IFLNK, S_IFDIR, S_IFIFO there
TS> remain only S_IFREG, S_IFBLK, S_IFCHR with the latter on Linux
TS> behaving like S_IFREG with 0 bytes of content. (As said on
TS> FreeBSD it could be a lseekable disk device.)
I’m not familiar with FreeBSD, but at least on NetBSD block
devices are paired with character devices used for ‘raw’
access; for example, the first GPT partition may end up
being /dev/dk0 (block) and /dev/rdk0 (character); a logical
volume could be /dev/vgfoo/lvbar (block) and /dev/vgfoo/rlvbar
(character); etc.
On Linux-based systems, such a device can apparently be
created with raw(8), but it’s not something I recall ever
needing to use.
http://manpages.debian.org/bullseye/raw.8
> I decided to regard a device with 0 lseekable size as not
> suitable for -cut_out.
An alternative would be to check if it’s possible to seek to
specified positions rather than to the end of file; e. g.:
$ strace -e trace=lseek -- dd skip=5 count=7 < /dev/zero > /dev/null
lseek(0, 0, SEEK_CUR) = 0
lseek(0, 2560, SEEK_CUR)= 0
7+0 records in
7+0 records out
3584 bytes (3.6 kB, 3.5 KiB) copied, 0.00119932 s, 3.0 MB/s
+++ exited with 0 +++
$
Can’t say I can readily suggest a good use case for such a
feature, though. Should one need to add a zero-filled file
of arbitrary size to the resulting filesystem (such as to
reserve space for a possible future dd(1) there), such
a (regular) file can easily be created with truncate(1)
(though it can be argued that -cut-out /dev/zero is a tad
clearer solution.)
> The test for suitable type rejects S_ISDIR, S_ISLNK, S_ISFIFO,
> and S_ISSOCK. So if an operating system offers non-POSIX types,
> it will be possible to test whether they are elsewise suitable.
> Please give the code a thorough test, especially with weird
> -cut_out arguments.
This looks like a job for a test suite. I gather there’s
none as of yet?
Meanwhile, I’ve noticed that the files created via -cut-out
inherit the permissions and m-time of the original file.
The former might be reasonable, but the latter doesn’t seem
to make much sense, at least for device files (whose m-times
tend to have no relation to their content proper.)
Worse still, if the target file is created in a yet-nonexistent
directory, the directory created inherits the permissions
of the source file as well (only adding +x where there’s r.)
I’d rather expect for missing directories to be created as
if with -mkdir.
Thoughts?
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#1010567: mirror listing update for fastmirror.pp.ua
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: fastmirror.pp.ua Type: leaf Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Ivan Barabash Country: UA Ukraine Trace Url: http://fastmirror.pp.ua/debian/project/trace/ Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua
Bug#1010561: mirror listing update for fastmirror.pp.ua
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: fastmirror.pp.ua Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Ivan Barabash Country: UA Ukraine Trace Url: http://fastmirror.pp.ua/debian/project/trace/ Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua
Bug#1010479: mirror listing update for fastmirror.pp.ua
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: fastmirror.pp.ua Type: leaf Archive-architecture: amd64 arm64 i386 Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Ivan Barabash Country: UA Ukraine Location: Kyiv Trace Url: http://fastmirror.pp.ua/debian/project/trace/ Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua
Bug#1010373: mirror submission for fastmirror.pp.ua
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: fastmirror.pp.ua Type: leaf Archive-architecture: amd64 i386 Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Ivan Barabash Country: UA Ukraine Location: Kyiv Trace Url: http://fastmirror.pp.ua/debian/project/trace/ Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua
Bug#1010098: xorriso: please allow -cut-out directly from block devices
>>>>> On 2022-04-24, Thomas Schmitt wrote: >>>>> Ivan Shmakov wrote: >> I’m filing this bug against versions from oldstable and stable, >> for that’s so far the only Debian packages’ versions I’ve tested >> for this issue. > As it is about an upstream wish: > The newest easily compilable and then usable version would be > http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz Not under http://ftp.gnu.org/gnu/xorriso/ , though? > It can be compiled without much dependencies and then used without > installation. See "Compilation, First Glimpse, Installation" in > https://www.gnu.org/software/xorriso/README_xorriso_devel > Said that, and now with my upstream hat on, i expect no difference > to versions 1.5.0 or 1.5.4 in respect to command -cut_out. It’d seem that I’ve missed an important detail or two in my original message. The patch suggested was against the following Git revisions of the libisofs and libisoburn: commit da00291519ad22c5bfa79c93ffeb04219bab0d7e Author: Thomas Schmitt AuthorDate: 2022-04-23 09:32:44 +0200 Commit: Thomas Schmitt CommitDate: 2022-04-23 09:32:44 +0200 Let the original isohybrid GPT obey system_area() option bit 17: GPT writable commit 0ef65a783765dbde79242ac41d5b9f2a495de1ec Author: Thomas Schmitt AuthorDate: 2022-04-23 14:09:30 +0200 Commit: Thomas Schmitt CommitDate: 2022-04-23 14:09:30 +0200 Updated change log and web page I’d frankly be surprised to learn that a proper release, such as 1.5.5, has features which a recent revision from Git master branch lacks. > So there is no need to get xorriso-1.5.5.tar.gz unless you want > to test a patch proposed by me. I’ll be checking the master branch from time to time, and hope to test the patch and report the results once it lands there. TIA. > I downloaded your 114.xorriso-1.diff and will study it for the > goal of enabling -cut_out for more file types. > I already see that it makes changes about fsrc_open(), which is a > central facility of libisofs. This means it will last several days > of study and pondering until i would be convinced of any change. The patch was intended, first and foremost, as a proof of concept; I hope I’ve identified /where/ the code needs to be changed, but I’m not going to claim familiarity with all the code paths involved, and as such cannot readily suggest /what/ changes are needed. As it is, I fully expect for the things to break. > Also i need to check whether your diff interferes with the > ability to backup a block device file as itself and not as bearer > of its content: > rm test.iso > xorriso -outdev test.iso -map /dev/sr0 /sr0 -commit -lsdl /sr0 -- > should produce even with a loaded BD_RE medium of 23 GiB a small ISO and > report a block device file in it > brw-rw1 024 11,0 Apr 24 14:15 '/sr0' FWIW, as a user, I’d expect an additional -follow option for this feature, such as: *seekable* If enabled, any non-regular seekable file (such as a block device) would be stored on image as a regular one with the contents taken from the original. The default is to store special files as-is. (See also the -cut_out option.) In the implementation, I’d rather see it not testing the file type specifically, aside of S_ISREG, S_ISDIR and S_ISLNK, but rather whether lseek (, 0, SEEK_END) gives a sane result, thus allowing for transparent support of novel or non-standard (platform-specific) file types. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1010098: xorriso: please allow -cut-out directly from block devices
Package: xorriso
Version: 1.5.0-1
Severity: wishlist
Control: found -1 1.5.2-1
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
I’m filing this bug against versions from oldstable and
stable, for that’s so far the only Debian packages’ versions
I’ve tested for this issue. Regardless, given that the
behavior is the same for a recent Git revision, and that
there doesn’t seem to be any relevant Debian-specific
patches under [1], it stands to reason that the requested
feature is not available in Debian testing and Sid, either.
[1] http://sources.debian.org/src/libisoburn/1.5.4-2/debian/patches/
It would be handy to be able to use xorriso(1) to backup
(portions) of block devices to optical media; yet it doesn’t
seem to be supported. E. g., on Buster:
bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
-cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
-find / -exec lsdl -- -commit
xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.
Drive current: -dev 'stdio:/tmp/cd4973.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with
'/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$
On Bullseye:
bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
-cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
-find / -exec lsdl -- -commit
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.
Drive current: -dev 'stdio:/tmp/cd1415.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with
'/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$
The problem is due to /both/ libisoburn (to a lesser degree)
and libisofs relying on struct stat .st_size field (and the
respective S_ISREG check.)
I’ve made a very crude patch (MIMEd) that replaces the
st_size checks for non-regular files with checks against the
size reported by lseek (, 0, SEEK_END), if available; and in
some cases forgoes the check for non-regular files altogether.
Consider, e. g.:
bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
-cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m
-find / -exec lsdl -- -commit
xorriso 1.5.5 : RockRidge filesystem manipulator, libburnia project.
Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, XXXm free
drwxr-xr-x1 00 0 Apr 24 10:16 '/'
-rw-rw1 0613631488 Apr 10 10:58 '/lvxxx_37m+13m'
xorriso : UPDATE : Writing: 3985s 58.2% fifo 0% buf 50%
ISO image produced: 6679 sectors
Written to medium : 6848 sectors at LBA 32
Writing to 'stdio:/tmp/cd14597.image' completed successfully.
xorriso : NOTE : Re-assessing -outdev 'stdio:/tmp/cd14597.image'
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1 nodes read in 1 seconds
Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 6679 data blocks, 13.0m data, XXXm free
Volume id: 'ISOIMAGE'
bash$
Checking if the intended data was indeed written to the image
with icat(1):
bash$ /usr/bin/time -- cmp -n 13M -i 37M:0 -- \
/dev/vgjubca-bk-i/lvepeci-x626512db \
<(icat /tmp/cd14597.image 1)
0.01user 0.04system 0:00.18elapsed 29%CPU (0avgtext+0avgdata 1088maxresident)k
27112inputs+0outputs (0major+95minor)pagefaults 0swaps
bash$
--
FSF associate member #7257 http://am-1.org/~ivan/
--- ./libisofs-da002915/libisofs/stream.c.~1~ 2022-04-23 07:32:44 +
+++ ./libisofs-da002915/libisofs/stream.c 2022-04-24 08:39:06.352583604 +
@@ -34,11 +34,27 @@
ino_t cut_out_serial_id = (ino_t)1;
static
+off_t fsrc_lseek_end_off(IsoFileSource *src)
+{
+/** For non-regular files, we check seekability
+and obtain SEEK_END position to use as size */
+off_t end, old, reset;
+old = iso_file_source_lseek (src, 0, 1);
+if (old < 0) { return -1; }
+end = iso_file_source_lseek (src, 0, 2);
+if
Bug#1009847: ext4 errors in lxc
Version: 2.38-4 Package: mount I've an lxc container running. It has its own set of soft raid HD mounted in /var/lib/lxc/[container-name] fstab UUID=01d94fc0-9012-4ba7-85ae-8037ceff9d58 /var/lib/lxc/[container-name] ext4 defaults,noatime 0 2 After upgrading mount and the related utilities and libraries (util-linux, uuid-runtime, libuuidl, libmount1...) in guest and host and a reboot, I started to get in host dmesg ext4_lookup:1785: inode #19404850: comm mc: iget: bad extra_isize 28338 (inode size 256) unmounted, fschk, all errors from the host seemed to be corrected, remounted, checked if most of the files in the container were still there, restarted the container, errors immediately reappeared in dmesg. unmounted, run smartctl short and long test with no error, run again fschk, restarted container, same problem. container is not starting anymore, but from the host the filesystem seems to be almost all there. I still haven't had time to safely downgrade the packages I suspect could be involved.
Bug#1003078: network-manager-gnome: Can't disable Networking/Wi-Fi, can't remove/edit connections (No polkit authorization)
Hi Michael, thanks for having a look at this. I updated packages a few days ago (I'm using `network-manager-gnome` version 1.24.0-2 now) and I just checked that all the issues that I described no longer happen. (Since you asked, I'm running plain i3wm on an X session.) I guess that the issue can be closed. Thanks again! Michael Biebl (2022-03-29 22:20:04 +0200) wrote: > Control: tags -1 + moreinfo > > Which desktop environment is this? > Can you provide steps how this can be reproduced? > > > On Mon, 03 Jan 2022 19:36:59 +0100 Ivan Vilata i Balaguer > wrote: > > Package: network-manager-gnome > > Version: 1.24.0-1 > > Severity: normal > > > > Dear Maintainer, > > > > After updating `network-manager-gnome`, the toggles "Enable Networking" and > > "Enable Wi-Fi" that show on right-click over the `nm-applet` appear active > > but > > grayed out and not responsive. Also, if I choose "Edit Connections...", and > > choose a connection in the "Network Connections" list, the "-" and gears > > buttons in the bottom remain grayed out and a tooltip shows up with > > "No polkit authorization to perform the action". […] -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
Bug#1004583: overwriting {,src}pkgcache.bin on near-every APT call strains flash
>>>>> On 2022-02-01 12:27:50 +0100, Julian Andres Klode wrote: > Control: reopen -1 I know there’re different approaches to this, but I believe that a report shouldn’t be closed so long as it describes a behavior that’s a. reproducible and b. known to affect at least some users. At the very least, keeping the report open will help prevent others from reporting the same issue over and over again. For the cases where the developer finds the existing behavior infeasible to alter, Debian BTS provides the ‘wontfix’ tag. > On Sun, Jan 30, 2022 at 07:10:34PM +, Ivan Shmakov wrote: >> A proper solution would be to move to some file format that >> allows in-place updates, such as Berkeley DB or SQLite. > No it would not be. The best we can do, and maybe should do > is move pkgcache.bin to /run. > In-place updates means _a lot_ of things can go wrong. Like you > forget to delete packages that are no longer in the repository. While I’m by no means familiar with the code base, this problem does not sound insurmountable. Moreover, this is something I personally would be interested in working on. > There’s also no way to change this in any case, the database > format is an integral part of the public API, it would take > decade(s) to switch to anything else. I wasn’t aware of this (though it does make sense, given the availability of alternative interfaces to APT functions.) Where this format, and its intended use, are documented? > Unfortunately I only thought about moving pkgcache.bin to > /run directly after sending the close email, but I think > that might be a reasonable compromise to discuss, and if > we support $XDG_RUNTIME_DIR/apt/pkgcache.bin as well, then > that would even get us caching for non-root users. I can’t say I readily see the utility of that, at least by itself. Sure, I’ve used apt-get as a non-root user to download lists and packages to copy to systems where the network connectivity was poor (or non-existent), but I had to point Dir::Cache and Dir::State::Lists to locations writable by that same user to achieve my goals, not just pkgcache.bin. > How to move that file out of /var/cache/apt is going to be > a tricky question, as that location is to some extend part > of the API as well - people might set Dir::Cache to /tmp/apt > and expect pkgcache.bin to end up in /tmp/apt. The APT configuration language doesn’t seem to provide a straightforward solution for invalidating a default for one option when another one is set by the user, indeed. Given that the current behavior is, AFAIK, problematic only in two cases (a. /var/cache/apt resides on an SD card; and b. block-level backups are used for the filesystem containing said directory; which is, incidentally, how I initially became aware of this behavior), both of which seem relatively rare, I think the best approach would be to either let the user decide (such as via debconf), or at least inform them of the potential problem. Furthermore, as installing Debian on an SD card (or similar flash-based device not rated for the amount of writing the updating of pkgcache.bin might take) doesn’t seem common outside of ARM-based SBCs, it may make sense to restrict the fix, whichever that might be, to ARM (arm64, armhf, armel) architectures. More directly, the fix can be applied if it can be detected with a degree of reliability at .postinst time that pkgcache.bin might end up on an SD card. (The necessary info is mostly there, see lsblk(8) output for instance, though I know of no straightforward way to map a file to the stack of devices it resides on. Presumably we can consider placing pkgcache.bin under /run if we find something like mmcblk* while traversing the stack upwards from the device that holds the filesystem.) > With regards to srcpkgcache.bin, which represents the available > packages, but no installed packages (pkgcache.bin is built from > it by adding the dpkg status file in-place, in-memory, and then > writing it back out), I think having that around after a reboot > is what we want such that you don’t need to rebuild the entire > cache each boot. FWIW, I mainly use Debian on Socket AM2-class hardware (which is to say, about 12 years old), and IME it takes something like 20 seconds to rebuild the cache. As such, I wouldn’t myself be much concerned with rebuilding the cache from scratch. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1004583: overwriting {,src}pkgcache.bin on near-every APT call strains flash
possible to move the cache to tmpfs;
consider, e. g.:
$ cat < /etc/apt/apt.conf.d/99-run-pkgcache
Dir::Cache::pkgcache "/run/apt/pkgcache.bin";
Dir::Cache::srcpkgcache "/run/apt/srcpkgcache.bin";
$ grep -F -- /run/apt < /etc/fstab
run.apt /run/apt tmpfs
rw,nodev,noexec,nosuid,mode=0755,size=256M,X-mount.mkdir 0 0
$
When RAM is also limited (which is to say, the filesystem size=
limit above isn’t negligible), it may make sense to remove the
files when not in use, such as by enabling the atime filesystem
option and using the following (untested) Cron job:
$ grep -F -- /run/apt < /etc/fstab
run.apt /run/apt tmpfs
rw,nodev,noexec,nosuid,mode=0755,size=256M,X-mount.mkdir,atime 0 0
$ cat < /etc/cron.hourly/cleanup-run-apt
#!/bin/sh
set -e
set -C -u
test -d /run/apt \
|| exit
## .
exec find /run/apt/ -maxdepth 1 \
-type f -amin +113 -cmin +113 \
-size +63k -name \*pkgcache.bin\* \
-execdir rm -- {} +
$
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#904572: move x11-utils to Suggests
>>>>> On 2018-07-25 10:27:15 +0200, Harald Dunkel wrote: [Please do not Cc: me, for I’m “on the list,” so to say, and I try to reserve my inbox for private communication only.] >>>>> Harald Dunkel writes: > Package: xterm > Version: 333-1 > xterm recommends x11-utils. Assuming the default configuration, this > brings in a huge list of packages unrelated to xterm's main purpose: > Running a shell or another cli program. Sample: […] > The following additional packages will be installed: >libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 >libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa >libllvm3.9 libpciaccess0 libtxc-dxtn-s2tc libxcb-glx0 >libxcb-shape0 libxtst6 libxv1 libxxf86dga1 libxxf86vm1 x11-utils >xbitmaps […] > If I manually omit x11-utils, then installing xterm uses just about > 2 MByte. Note that it’s also possible to configure apt_preferences(5) to avoid installation of unwanted packages (regardless of them being recommended.) E. g. (though in this case it’s likely libgl1-mesa-dri that rather should be avoided, see below): $ cat < /etc/apt/preferences.d/55-no-x11-utils.pref Explanation: The x11-utils package is not welcome on this system. Package: x11-utils Pin: release c=main Pin-Priority: -42 $ […] What’s going on here is that x11-utils contains, among others, the /usr/bin/xdriinfo program, which is linked against libGL. As such, the binary package automatically gets Depends: libgl1, which is in turn dependent on libglx0 ← libglx-mesa0 ← libgl1-mesa-dri, the last of which is itself large enough, and also brings in a whole world of dependencies, as I’ve noted in http://bugs.debian.org/960133 . There’re several ways to resolve the issue, one of which is indeed to move luit into a package of its own, though I can’t say I’m particularly fond of practices that lead to the expansion of the Packages files, as well as /var/lib/dpkg/. FWIW, I haven’t noticed any ill effects due to the workaround described in #960133 on Buster, but haven’t yet tested it on Bullseye. Given that DRI modules are more often than not useless without appropriate proprietary GPU software, downgrading dependency on libgl1-mesa-dri to Recommends: makes every sense to me. Perhaps we should try to find and merge all such bugs together and record ‘affects’ accordingly, to give the issue a tad more attention and better cooperation / coordination? Thoughts? -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#880499: apt-cache rdepends outputs too many dependencies
Control: tags -1 moreinfo Control: severity -1 minor >>>>> Tom writes: [Please do not Cc: me, for I’m “on the list,” so to say, and I try to reserve my inbox for private communication only.] > I try to find all reverse dependencies of a certain package. I’m > only interested in “Depends” relations, no Recommends, Suggests, etc. > So, for instance, for the aptitude package, I do: > $ apt-cache rdepends "aptitude" --installed \ >--no-pre-depends \ As an aside, I’m going to question whether omitting Pre-Depends: is really what you’re looking for, as Pre-Depends: is essentially a stronger / specialized form of Depends:. For instance, Debian Policy Manual states [1]: Pre-Depends This field is like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency […] [1] http://debian.org/doc/debian-policy/ch-relationships.html >--no-suggests --no-recommends --no-conflicts --no-breaks \ >--no-replaces --no-enhances Also note that at some point apt-cache acquired the --important option, which seems effectively the same as the above [2] (though the man page somehow does not mention rdepends here): -i, --important Print only important dependencies; for use with unmet and depends. Causes only Depends and Pre-Depends relations to be printed. Configuration Item: APT::Cache::Important. [2] http://manpages.debian.org/unstable/apt/apt-cache.8.en.html > aptitude > Reverse Depends: > aptitude:i386 > aptitude:i386 > aptitude:i386 > aptitude:i386 > aptitude:i386 > But there are no reverse dependencies on aptitude, as reported be > aptitude: > i aptitude > [… some lines skipped …] > --\ Packages which depend on aptitude (23) > --\ Depends (5) > p aptitude-robot 1.5.1-1 […] What I see above is actually exactly the opposite: the apt-cache call reports the aptitude:i386 package several times over, but /no/ (installed, due to the --install option) packages dependent on it, while aptitude reports a number of (non-installed, presumably) dependencies, such as aptitude-robot. Were there dependent packages satisfying the criteria given, the output would contain something like: Reverse Depends: aptitude-robot aptitude:amd64 The output may be a tad confusing (and likely worth fixing), but that’s pretty much the only issue I can discern here. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1003078: network-manager-gnome: Can't disable Networking/Wi-Fi, can't remove/edit connections (No polkit authorization)
Package: network-manager-gnome Version: 1.24.0-1 Severity: normal Dear Maintainer, After updating `network-manager-gnome`, the toggles "Enable Networking" and "Enable Wi-Fi" that show on right-click over the `nm-applet` appear active but grayed out and not responsive. Also, if I choose "Edit Connections...", and choose a connection in the "Network Connections" list, the "-" and gears buttons in the bottom remain grayed out and a tooltip shows up with "No polkit authorization to perform the action". Since I'm not running the whole GNOME, I installed `policykit-1-gnome`, ran `/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1` and restarted `nm-applet` with same results. As my user belongs to `netdev`, I also tried the `/etc/polkit-1/localauthority/50-local.d/WHATEVER.pkla` config mentioned in #642136 to no avail (after restarting polkit and NetworkManager): [Adding or changing system-wide NetworkManager connections] Identity=unix-group:netdev Action=org.freedesktop.NetworkManager.settings.modify.system ResultAny=no ResultInactive=no ResultActive=yes Other applets like `nm-tray` allow me to disable Networking/Wi-Fi without issues, and `nmtui-*` tools allow me to edit connections just fine, so it seems specific to this package and not `network-manager`. Thanks a lot, and cheers! -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-gnome depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-3 ii dbus-x11 [dbus-session-bus] 1.12.20-3 ii libatk1.0-0 2.36.0-3 ii libayatana-appindicator3-10.5.90-5 ii libc6 2.33-1 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.70.2-1 ii libgtk-3-03.24.31-1 ii libjansson4 2.13.1-1.1 ii libmm-glib0 1.18.4-1 ii libnm01.32.12-1 ii libnma0 1.8.32-1 ii libnotify40.7.9-3 ii libpango-1.0-01.48.10+ds1-1 ii libpangocairo-1.0-0 1.48.10+ds1-1 ii libsecret-1-0 0.20.4-2 ii libselinux1 3.3-1+b1 ii lxqt-policykit [polkit-1-auth-agent] 0.16.0-1 ii network-manager 1.32.12-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7+b1 Versions of packages network-manager-gnome recommends: ii dunst [notification-daemon] 1.5.0-1+b1 ii gnome-keyring 40.0-3 ii iso-codes 4.8.0-1 ii lxqt-notificationd [notification-daemon] 0.16.0-1 ii mobile-broadband-provider-info20210805-1 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome pn network-manager-openvpn-gnome pn network-manager-pptp-gnome pn network-manager-vpnc-gnome -- no debconf information
Bug#1002816: openssh-client problem with update-alternatives
Package: openssh-client Version: 1:8.7p1-3 Upgrading from 1:8.7p1-2 to -3 I get Setting up openssh-client (1:8.7p1-3) ... update-alternatives: and can't be the same Use 'update-alternatives --help' for program usage information. dpkg: error processing package openssh-client (--configure): installed openssh-client package post-installation script subprocess returned error exit status 2 -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#1001004: dkms not removing modules for purged kernels
Package: dkms Version: 2.8.7-2 What I get when I purge old kernels is... /etc/kernel/prerm.d/dkms: dkms: removing: (5.14.0-4-amd64) (x86_64) Error! Arguments and are not specified. Usage: remove / or remove -m / or remove -m -v modules have to be removed manually specifying module and kernel version I guess this started a couple of dkms releases ago, but at that time I didn't have the time to report and later I forgot about the problem. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#741537: pssh: IPv6 host address processing broken
Hello Hilmar, I tested the 2.3.4 packages and yes, the bug still seems to be there. `:(` Thanks for the heads up! Hilmar Preuße (2021-09-17 00:11:32 +0200) wrote: > Am 13.03.2014 um 16:37 teilte Ivan Vilata i Balaguer mit: > > Hi, > > > The handling of IPv6 addresses is broken since the > > ``parse_host_entry()`` function in ``psshutil.py`` thinks the colons > > in it are an indication for a port and the last component is taken > > apart. Enclosing the address in brackets doesn't work either because > > the host name resolution includes the brackets around the IP > > address. > > > I'm pretty sure the issue is still in 2.3.4 available I'm currently > packaging for Debian unstable. Are you nevertheless willing to test that > version, in case it has been solved in the meantime? > > https://freeshell.de/hille42/pssh_2.3.4/ > > Hilmar -- Ivan Vilata i Balaguer -- https://elvil.net/
Bug#242510: screen: spins when pasting
Control: found -1 4.6.2-3+deb10u1 Control: found -1 4.8.0-6 >>>>> On 2004-04-06 22:31:43 -0400, Allan Wind wrote: > Package: screen > Version: 4.0.2-3 > Severity: normal > I have been seeing an issue for a while, where screen appears to be > going into a busy loop when pasting data into vim. Not exactly sure > how to reproduce this, but something along these lines seem to always > work when the data is important (but I cannot reproduce it consistently): […] > When it works, it takes ~3 sec paste the 10k lines on my box, and when > you hit the issue I never seen it terminate. I was able to reproduce it with both 4.6.2-3+deb10u1 and 4.8.0-6; it seems, however, that an important part is to signal Screen while it sends the data down to the application; such as with: 1. $ seq 1 0x10 | fmt -w78 > /tmp/screen-exchange . 2. $ screen ; then load the file with C-a < . 3. $ vim.tiny ; start pasting the data there with C-a ] . 4. Press ^C while Screen is still sending the data. 5. Screen appears to enter an infinite loop: 100% CPU utilization, no syscalls seen via strace(1), etc. Given that this bug effectively results in the loss of a given Screen session, possibly with all the (‘unsaved’) data therein, I believe it deserves a higher Severity: . (Could #524304 be possibly related?) As a workaround, some applications may be salvaged with reptyr(1); like: 1. Find out the PID of the ‘broken’ session: $ pgrep --full -u"$(id -u)" -- ^SCREEN\\b 1234 $ (It’s possible to $ kill -STOP the process here so that it no longer consumes CPU cycles.) 2. Find out the PIDs of the programs running under: $ pstree -Apl -- 1234 screen(1234)-+-vim(2468) `-lynx(5678) 3. Move said programs to another Screen session: $ screen -t vim 10 reptyr -V -- 2468 $ screen -t lynx 11 reptyr -V -- 5678 4. Once all the programs are recovered, terminate their original Screen instance: $ kill -- 1234 (If the process was stopped before, as suggested above, also resume it with $ kill -CONT , so it can process the signal sent and terminate.) -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#992554: not really a libgpg-error0 problem
Even if after upgrade of libgpg-error0 newer version of tor seemed to work... after a reboot it stopped working again. Downgrading to 0.4.5.9-1, this time even without downgrading libgpg-error0, makes it work again. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#992554: service seems to start regularly but it doesn't work
I had the same problem, downgrading made it works... Later on I did a safe-upgrade that probably brought in some related library and now it is working. [UPGRADE] e2fsprogs:amd64 1.46.2-2 -> 1.46.4-1 [UPGRADE] libcom-err2:amd64 1.46.2-2 -> 1.46.4-1 [UPGRADE] libext2fs2:amd64 1.46.2-2 -> 1.46.4-1 [UPGRADE] libgpg-error0:amd64 1.38-2 -> 1.42-2 [UPGRADE] libss2:amd64 1.46.2-2 -> 1.46.4-1 [UPGRADE] logsave:amd64 1.46.2-2 -> 1.46.4-1 [UPGRADE] node-ansi-escapes:amd64 5.0.0-1 -> 5.0.0+really.4.3.1-1 [UPGRADE] tor:amd64 0.4.5.9-1 -> 0.4.5.10-1 [UPGRADE] tor-geoipdb:amd64 0.4.5.9-1 -> 0.4.5.10-1 Probably newer libgpg-error.so.0 -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#755202: NHG
Hello good day, checking to see if you were in receipt of my previous message?
Bug#988330: Fixed in new upstream version 1.125
This is now fixed in the new upstream version 1.125. -- _ivan
Bug#988330: libbusiness-us-usps-webtools-perl: HTTP access shutting down June 24th, 2021
Package: libbusiness-us-usps-webtools-perl Version: 1.124-1 Severity: grave Tags: upstream Justification: renders package unusable Forwarded: https://github.com/ssimms/business-us-usps-webtools/issues/2 USPS is sending notices that HTTP access will be turned off shortly, in favor of HTTPS. Given that is a web service that will break in the wild, in addition to a regular update for unstable, we should update buster (and stretch) via stable-updates (and oldstable-updates). I can confirm that a package built with a simple s/http/https/ replacement works with a live USPS account, at least on buster. Note that since buster, the module has been rewritten to use Mojo::UserAgent instead of LWP::UserAgent. -- Ivan Kohler President and Head Geek, Freeside Internet Services, Inc. http://freeside.biz/ Debian GNU/Linux developer | CPAN author | pet person | ski addict
Bug#985469: [xsct]
Package: xsct Version: SoapFault - faultcode: 'SOAP-ENV:Server' faultstring: 'Processing Failure' faultactor: 'null' detail: org.kxml2.kdom.Node@2ffd1e5 Severity: Tags: X-Debbugs-CC: Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (orineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines ***
Bug#985317: not a libc6 problem as in #971812?
Unless something regarding libc6 changed in libgegl from 0.4.26 to 0.4.28 I wonder if this problem is really related to this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971812 since downgrading makes gimp work again and because I don't get the "undefined symbol: __exp_finite" running gimp from the cli. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#985317: libgegl
Culprit seems to be [UPGRADE] libgegl-0.4-0:amd64 1:0.4.26-2 -> 1:0.4.28-1 [UPGRADE] libgegl-common:amd64 1:0.4.26-2 -> 1:0.4.28-1 Same problem with 1:0.4.28-2 this seems to be related https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971812 BTW I'm running a mix of testing/unstable and libc6 is at 2.31-9 downgrading fixed the problem. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#981288: /usr/bin/jacal: references build-time dir; vicinity lacks a /; bashism
Package: jacal
Version: 1c7-1
The /usr/bin/jacal script provided by the current jacal package
fails to set SCHEME_LIBRARY_PATH and JACALDIR correctly:
#! /bin/sh
SCHEME_LIBRARY_PATH=/usr/share/slib
export SCHEME_LIBRARY_PATH
JACALDIR=/build/jacal-PHwb3U/jacal-1c7/debian/jacal/usr/lib/jacal/
VERSION=1c7
Specifically, SCHEME_LIBRARY_PATH (library-vicinity) is expected
to be a prefix (i. e., contain a trailing /), not directory name;
and JACALDIR somehow contains build-time prefix (in place of
a run-time one.)
Also, while we’re at it, I think that the script should make it
possible for the user to override either or both of the variables.
That is, I’d rather have it start with:
#! /bin/sh
: "${SCHEME_LIBRARY_PATH:=/usr/share/slib/}"
export SCHEME_LIBRARY_PATH
: "${JACALDIR:=/usr/lib/jacal/}"
VERSION=1c7
(Which is not without its downsides, but is otherwise consistent
with how, say, shells allow for PATH to be overridden arbitrarily.)
FTR, the built-time directory name capture is somehow despite
debian/rules [1] containing:
# These are from upstream's install target, turned into correctness.
debian/jacal/usr/bin/jacal:
-mkdir -p $$(dirname $@)
echo '#! /bin/bash' > $@
echo JACALDIR=/usr/lib/jacal/ >> $@
echo VERSION=$(version) >> $@
cat jacal.sh>> $@
chmod +x $@
[1] http://sources.debian.org/data/main/j/jacal/1c7-1/debian/rules
--
FSF associate member #7257 http://am-1.org/
Bug#890343: linux: make fq_codel default for default_qdisc
Hello. Not an expert nor kernel developer, etc., just simple sysadmin here, but will answer anyway since nobody did yet. I think we want the mq qdisc to distribute the load between cores, to support very high speed network cards or too slow CPUs. Also, if net.core.default_qdisc = fq_codel is used, it also has the mq qdisc and fq_codel childs for each CPU core, so that's the default behavior in other distros. I guess being under mq it could impact fq_codel's ability somewhat, but it's better to support all the hardware spectrum by default, otherwise we should use cake as default since it can handle up to 10Gbit/s without troubles; we don't, because Debian is a generic operating system so it should work on embedded devices, laptops, workstations and big iron servers... Also, I don't see a problem with statically linking fq_codel if we are using it as default, since it will probably get loaded anyway... Thanks for pushing this forward, doing these tests, etc.!!! Bye. El 7/1/21 a las 21:12, Noah Meyerhans escribió: On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote: #890343 was originally opened against systemd asking to install the upstream systemd sysctl.d/50-default.conf file that sets: net.core.default_qdisc = fq_codel As explained in #950701 (and the systemd debian changelog) the debian systemd maintainers felt that systemd in debian should not be changing kernel policies (and I agree). So #890343 was reassigned to linux to consider changing the default. fq_codel is better in every way than pfifo_fast and I am unaware of any reason why it would not be a better default. (but don't trust me, ask the kernel networking experts) Can we change it? I strongly agree that we should make this change for the bullseye release. I'm looking into provding a patch to implement the switch to fq_codel by default, but it appears to require something more than just a kernel config change. I have tried the following with the 5.10 kernel from the current sid branch: CONFIG_NET_SCH_FQ_CODEL=m CONFIG_DEFAULT_FQ_CODEL=y CONFIG_DEFAULT_NET_SCH="fq_codel" Then we don't see any change at all to the qdisc in use: admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r) CONFIG_NET_SCH_FQ_CODEL=m CONFIG_DEFAULT_FQ_CODEL=y CONFIG_DEFAULT_NET_SCH="fq_codel" admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc net.core.default_qdisc = pfifo_fast admin@ip-10-0-0-162:~$ tc qdisc show dev ens5 qdisc mq 0: root qdisc pfifo_fast 0: parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 admin@ip-10-0-0-162:~$ ip link show dev ens5 2: ens5: mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff altname enp0s5 If we statically link the fq_codel module into the kernel, then we see: admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r) CONFIG_NET_SCH_FQ_CODEL=y CONFIG_DEFAULT_FQ_CODEL=y CONFIG_DEFAULT_NET_SCH="fq_codel" admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc net.core.default_qdisc = fq_codel admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5 qdisc mq 0: root qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 admin@ip-10-0-0-162:~$ ip link show dev ens5 2: ens5: mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff altname enp0s5 So in this case, we have fq_codel configured, but not as the root qdisc for the interface. If we manually set it: admin@ip-10-0-0-162:~$ sudo /sbin/tc qdisc add root dev ens5 fq_codel Then we get the following configuration: admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5 qdisc fq_codel 8001: root refcnt 3 limit 10240p flows 1024 quantum 9015 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 admin@ip-10-0-0-162:~$ ip link show dev ens5 2: ens5: mtu 9001 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff altname enp0s5 I believe that this is what we want. Is that accurate? The recent thread at https://www.mail-archive.com/netdev@vger.kernel.org/msg380410.html also seems relevant. noah -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ Freelance C++/PHP programmer and GNU/Linux systems administrator. The sky is not the limit!
Bug#978671: apt http transport gets stuck after package download
On Tue, Dec 29, 2020 at 1:27 PM Ivan Babrou wrote: > > Package: apt > Version: 1.8.2.1 > Severity: normal > Tags: patch > > Dear Maintainer, > > On Debian Buster we're seeing 30s timeouts when downloading > a particular set of debian packages from an internal repo: > > ``` > $ time apt-get download -y rubygem-stud rubygem-mustache rubygem-insist > rubygem-pleaserun rubygem-fpm > ... > Fetched 451 kB in 30s (15.0 kB/s) > > real0m31.022s > user0m0.923s > sys 0m0.080s > ``` > > The issue is fixed in the following commit in apt 2.1.9: > > ``` > commit 08f05aa8beb58fa32485e2087eb21a9f3cb267bb > Author: Julian Andres Klode > Date: Mon Jun 29 14:03:21 2020 +0200 > > http: Redesign reading of pending data > > Instead of reading the data early, disable the timeout for the > select() call and read the data later. Also, change Read() to > call only once to drain the buffer in such instances. > > We could optimize this to call read() multiple times if there > is also pending stuff on the socket, but that it slightly more > complex and should not provide any benefits. > ``` > > Please consider backporting this into Debian Buster, > as it fixes the problem and the patch itself applies cleanly. > > -- System Information: > Debian Release: 10.6 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.70 > Kernel taint flags: TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: unable to detect > > Versions of packages apt depends on: > ii adduser 3.118 > ii debian-archive-keyring 2019.1 > ii gpgv2.2.12-1+deb10u1 > ii libapt-pkg5.0 1.8.2.1 > ii libc6 2.28-10 > ii libgcc1 1:8.3.0-6 > ii libgnutls30 3.6.7-4+deb10u5 > ii libseccomp2 2.5.1-1 > ii libstdc++6 8.3.0-6 > > Versions of packages apt recommends: > ii ca-certificates 20200601~deb10u1 > > Versions of packages apt suggests: > pn apt-doc > pn aptitude | synaptic | wajig > ii dpkg-dev 1.19.7 > ii gnupg2.2.12-1+deb10u1 > ii gnupg2 2.2.12-1+deb10u1 > pn powermgmt-base > > -- no debconf information CC'd Julian, who is the author of the patch.
Bug#978671: apt http transport gets stuck after package download
Package: apt Version: 1.8.2.1 Severity: normal Tags: patch Dear Maintainer, On Debian Buster we're seeing 30s timeouts when downloading a particular set of debian packages from an internal repo: ``` $ time apt-get download -y rubygem-stud rubygem-mustache rubygem-insist rubygem-pleaserun rubygem-fpm ... Fetched 451 kB in 30s (15.0 kB/s) real0m31.022s user0m0.923s sys 0m0.080s ``` The issue is fixed in the following commit in apt 2.1.9: ``` commit 08f05aa8beb58fa32485e2087eb21a9f3cb267bb Author: Julian Andres Klode Date: Mon Jun 29 14:03:21 2020 +0200 http: Redesign reading of pending data Instead of reading the data early, disable the timeout for the select() call and read the data later. Also, change Read() to call only once to drain the buffer in such instances. We could optimize this to call read() multiple times if there is also pending stuff on the socket, but that it slightly more complex and should not provide any benefits. ``` Please consider backporting this into Debian Buster, as it fixes the problem and the patch itself applies cleanly. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.70 Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.12-1+deb10u1 ii libapt-pkg5.0 1.8.2.1 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4+deb10u5 ii libseccomp2 2.5.1-1 ii libstdc++6 8.3.0-6 Versions of packages apt recommends: ii ca-certificates 20200601~deb10u1 Versions of packages apt suggests: pn apt-doc pn aptitude | synaptic | wajig ii dpkg-dev 1.19.7 ii gnupg2.2.12-1+deb10u1 ii gnupg2 2.2.12-1+deb10u1 pn powermgmt-base -- no debconf information
Bug#974084: Rework Devuan targets into separate entities
On Mon, Nov 09, 2020 at 08:17:37PM +0100, Ivan J. wrote: > Package: debootstrap > Version: 1.0.123 > > Hi. I've submitted patches to debootstrap which reimplement the logic of > the Devuan targets (ceres, chimaera, beowulf, ascii) into being separate > from the "sid" target. I believe the patches are pretty straightforward, > but if there are any questions or suggestions, don't hesitate to tell :) > > The patches can be found on salsa: > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/50 Hi. It's been a while. Will anybody attend this? Best regards, Ivan
Bug#974084: Rework Devuan targets into separate entities
Package: debootstrap Version: 1.0.123 Hi. I've submitted patches to debootstrap which reimplement the logic of the Devuan targets (ceres, chimaera, beowulf, ascii) into being separate from the "sid" target. I believe the patches are pretty straightforward, but if there are any questions or suggestions, don't hesitate to tell :) The patches can be found on salsa: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/50 I hope this reaches you well. Thank you. Best regards, Ivan
Bug#974048: ITP: devuan-keyring -- GnuPG archive key of the devuan repository
I've gone forward and uploaded the package to salsa and mentors. A version was built, but there are lintian issues which I have fixed in git HEAD, but I will not build this yet. I will need someone to sign my GnuPG key and I assume it will have to be added to debian-keyring. My key's fingerprint is B876CB44FA1B0274. It can be retrieved from: * https://pgp.mit.edu/pks/lookup?op=get=0xB876CB44FA1B0274 * https://parazyd.org/fa1b0274.asc This would be used for the verification of keyrings in debian/rules: https://salsa.debian.org/parazyd/devuan-keyring/-/blob/master/debian/rules#L11 Would anyone kindly volunteer to sign this key so we can proceed with the package build? Thank you very much! Best regards, Ivan
Bug#974048: ITP: devuan-keyring -- GnuPG archive key of the devuan repository
Package: wnpp Severity: ITP X-Debbugs-CC: debian-de...@lists.debian.org Greetings. I was wondering if it would be possible to start maintaining the devuan-keyring package on salsa, and have it being built upstream in Debian? This way it would be possible to unify our efforts in debootstrap maintenance, and provide a separate script for Devuan releases, much like what is happening with Ubuntu and the gutsy target right now. If this is possible, following it, I would submit a patch to debootstrap where an extra Devuan target would be added, instead of the current symlinks to "sid". Thank you for your consideration, Ivan
Bug#974047: TAG: devuan-keyring -- GnuPG archive key of the devuan repository
Package: wnpp Severity: ITP X-Debbugs-CC: debian-de...@lists.debian.org Greetings. I was wondering if it would be possible to start maintaining the devuan-keyring package on salsa, and have it being built upstream in Debian? This way it would be possible to unify our efforts in debootstrap maintenance, and provide a separate script for Devuan releases, much like what is happening with Ubuntu and the gutsy target right now. If this is possible, following it, I would submit a patch to debootstrap where an extra Devuan target would be added, instead of the current symlinks to "sid". Thank you for your consideration, Ivan
Bug#973773: libraries in kde?
5.14.2+dfsg-3 -> 5.15.1+dfsg-3 [UPGRADE] qml-module-qtquick-privatewidgets:amd64 5.14.2-2 -> 5.15.1-2 [UPGRADE] qml-module-qtquick-scene3d:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-3 [UPGRADE] qml-module-qtquick-templates2:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-2 [UPGRADE] qml-module-qtquick-window2:amd64 5.14.2+dfsg-3 -> 5.15.1+dfsg-3 [UPGRADE] qml-module-qtquick-xmllistmodel:amd64 5.14.2-2 -> 5.15.1-2 [UPGRADE] qml-module-qtquick2:amd64 5.14.2+dfsg-3 -> 5.15.1+dfsg-3 [UPGRADE] qml-module-qtsensors:amd64 5.14.2-2 -> 5.15.1-2 [UPGRADE] qml-module-qtwayland-compositor:amd64 5.14.2-2 -> 5.15.1-3 [UPGRADE] qml-module-qtwebengine:amd64 5.14.2+dfsg1-5 -> 5.15.1+dfsg-5 [UPGRADE] qml-module-qtwebkit:amd64 5.212.0~alpha4-5 -> 5.212.0~alpha4-7 [UPGRADE] qmmp:amd64 2:1.4.2-dmo1 -> 2:1.4.2-dmo2 [UPGRADE] qt5-assistant:amd64 5.14.2-3 -> 5.15.1-2 [UPGRADE] qt5-gtk-platformtheme:amd64 5.14.2+dfsg-6 -> 5.15.1+dfsg-2 [UPGRADE] qt5-gtk2-platformtheme:amd64 5.0.0+git23.g335dbec-4 -> 5.0.0+git23.g335dbec-4+b1 [UPGRADE] qt5-image-formats-plugins:amd64 5.14.2-2 -> 5.15.1-2 [UPGRADE] qt5-style-plugin-cleanlooks:amd64 5.0.0+git23.g335dbec-4 -> 5.0.0+git23.g335dbec-4+b1 [UPGRADE] qt5-style-plugin-motif:amd64 5.0.0+git23.g335dbec-4 -> 5.0.0+git23.g335dbec-4+b1 [UPGRADE] qt5-style-plugin-plastique:amd64 5.0.0+git23.g335dbec-4 -> 5.0.0+git23.g335dbec-4+b1 [UPGRADE] qt5-style-plugins:amd64 5.0.0+git23.g335dbec-4 -> 5.0.0+git23.g335dbec-4+b1 [UPGRADE] qtattributionsscanner-qt5:amd64 5.14.2-3 -> 5.15.1-2 [UPGRADE] qtspeech5-speechd-plugin:amd64 5.14.2-2 -> 5.15.1-2 [UPGRADE] qttools5-dev-tools:amd64 5.14.2-3 -> 5.15.1-2 [UPGRADE] qtwayland5:amd64 5.14.2-2 -> 5.15.1-3 [UPGRADE] vala-panel-appmenu-common:amd64 0.7.5+dfsg1-1 -> 0.7.6+dfsg1-1 [UPGRADE] xfce4-appmenu-plugin:amd64 0.7.5+dfsg1-1 -> 0.7.6+dfsg1-1 [UPGRADE] xfce4-sensors-plugin:amd64 1.3.0-2+b1 -> 1.3.0-3 [UPGRADE] xfce4-session:amd64 4.14.2-1 -> 4.14.2-2 [UPGRADE] xfwm4:amd64 4.14.5-1 -> 4.14.6-1 I hope it helps. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#973773: lost support with kwallet
Package: subversion Version: 1.14.0-3 upgrading from 1.14.0-2+b1 svn can't use kwallet. It keeps asking for the password. Downgrading subversion and libsvn1 things work as usual. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files
Hello. "¡Lo prometido es deuda!" as we say in Uruguay (what is promised is a debt). Tested your packages and now I can see correctly all the scanners, local and networked ones! So everything looks good to push those to Debian Stretch. Thanks a lot for doing all this! Greetings from another Allegro user ;-) El sáb., 3 de oct. de 2020 a la(s) 13:53, Sylvain Beucler (b...@beuc.net) escribió: > > Hi, > > The package is in this state since Aug 17, I think we can afford to wait > a few more days for testing. > So yes, please do test on Tuesday. > > Cheers! > Sylvain > > On 03/10/2020 00:41, Ivan Baldo wrote: > > Hello. > > The soonest I could try to check, is this Tuesday 6th 19:00 -0300, sorry. > > Let me know if that's useful or too late. > > Thanks! > > > > El vie., 2 de oct. de 2020 a la(s) 10:22, Sylvain Beucler > > (b...@beuc.net) escribió: > >> > >> Hi, > >> > >> On 02/10/2020 13:51, Ivan Baldo wrote: > >>> El vie., 2 de oct. de 2020 a la(s) 06:48, Sylvain Beucler > >>> (b...@beuc.net) escribió: > >>>> > >>>> Hi, > >>>> > >>>>> El jue., 1 de oct. de 2020 a la(s) 19:32, Sylvain Beucler > >>>>> (b...@beuc.net) escribió: > >>>>>> This could be due to a bug when building the 'all' and 'amd64' packages > >>>>>> separately. > >>>> > >>>> I can reproduce the 2 debdiff-s with 'debuild -A' and 'debuild -B' > >>>> respectively. > >>>> > >>>> I'm currently backporting fixes from 1.0.27-1~experimental3 to fix the > >>>> issue, and updating our procedures to test this case in the future. > >>> > >>> Great, thanks a lot!!! > >> > >> I prepared a new package at: > >> https://www.beuc.net/tmp/debian-lts/sane-backends/ > >> that I plan to upload as a regression fix. > >> > >> (Note: sane-dll is now consistently removed, as it previously evaded > >> deletion only in amd64, see #971592.) > >> > >> Can you test it? > >> > >> Cheers! > >> Sylvain > > > > > > -- Ivan Baldo - iba...@gmail.com - http://ibaldo.codigolibre.net/ Freelance C++/PHP programmer and GNU/Linux systems administrator. The sky isn't the limit!
Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files
Hello. The soonest I could try to check, is this Tuesday 6th 19:00 -0300, sorry. Let me know if that's useful or too late. Thanks! El vie., 2 de oct. de 2020 a la(s) 10:22, Sylvain Beucler (b...@beuc.net) escribió: > > Hi, > > On 02/10/2020 13:51, Ivan Baldo wrote: > > El vie., 2 de oct. de 2020 a la(s) 06:48, Sylvain Beucler > > (b...@beuc.net) escribió: > >> > >> Hi, > >> > >>> El jue., 1 de oct. de 2020 a la(s) 19:32, Sylvain Beucler > >>> (b...@beuc.net) escribió: > >>>> This could be due to a bug when building the 'all' and 'amd64' packages > >>>> separately. > >> > >> I can reproduce the 2 debdiff-s with 'debuild -A' and 'debuild -B' > >> respectively. > >> > >> I'm currently backporting fixes from 1.0.27-1~experimental3 to fix the > >> issue, and updating our procedures to test this case in the future. > > > > Great, thanks a lot!!! > > I prepared a new package at: > https://www.beuc.net/tmp/debian-lts/sane-backends/ > that I plan to upload as a regression fix. > > (Note: sane-dll is now consistently removed, as it previously evaded > deletion only in amd64, see #971592.) > > Can you test it? > > Cheers! > Sylvain -- Ivan Baldo - iba...@gmail.com - http://ibaldo.codigolibre.net/ Freelance C++/PHP programmer and GNU/Linux systems administrator. The sky isn't the limit!
