Bug#1056311: lirc: FTBFS on hurd-i386
Source: lirc
Version: 0.10.1-7.2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org
Hi,
lirc FTBFS on hurd-i386. (Built in the past, last successful build version was
0.10.1-5.2)
This is due to usage of __u32 in the patch 0007-lirc-gpio-ir-0.10.patch, which
is not defined on GNU/Hurd. This patch was added to version 0.10.1-6 in 2019.
Attached is that patch updated to use uint32_t which is defined. (In fact
uint32_t is used in an earlier statement in that patch.)
Moreover, MODINFO is not available on GNU/Hurd since Hurd does not use modules
at all. This change is reflected in the second patch for debian/rules.
The two patches enabling a successful build on GNU/Hurd are attached:
The updated patch 0007-lirc-gpio-ir-0.10.patch
and debian_rules.patch.
I'm sending this bug report to Debian instead of upstream since this package has
been NMU-ed twice, and the second patch is Debian-specific.
Thanks!
From: Debian Lirc Team
Date: Thu, 12 May 2022 21:07:56 +0200
Subject: lirc-gpio-ir-0.10
Origin: https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir-0.10.patch
Bug-Debian: bugs.debian.org/931078
---
lib/config_file.c| 2 +-
lib/ir_remote.h | 9 +++--
lib/irrecord.c | 41 +++--
lib/lirc/ir_remote.h | 9 +++--
tools/mode2.cpp | 18 +++---
5 files changed, 57 insertions(+), 22 deletions(-)
Index: lirc-0.10.1/lib/config_file.c
===
--- lirc-0.10.1.orig/lib/config_file.c
+++ lirc-0.10.1/lib/config_file.c
@@ -71,7 +71,7 @@ struct void_array {
typedef void* (*array_guest_func)(void* item, void* arg);
-#define LINE_LEN 1024
+#define LINE_LEN 4096
#define MAX_INCLUDES 10
const char* whitespace = " \t";
Index: lirc-0.10.1/lib/ir_remote.h
===
--- lirc-0.10.1.orig/lib/ir_remote.h
+++ lirc-0.10.1/lib/ir_remote.h
@@ -110,12 +110,17 @@ static inline ir_code reverse(ir_code da
static inline int is_pulse(lirc_t data)
{
- return data & PULSE_BIT ? 1 : 0;
+ return ((data & LIRC_MODE2_MASK)==LIRC_MODE2_PULSE) ? 1 : 0;
}
static inline int is_space(lirc_t data)
{
- return !is_pulse(data);
+ return ((data & LIRC_MODE2_MASK)==LIRC_MODE2_SPACE) ? 1 : 0;
+}
+
+static inline int is_timeout(lirc_t data)
+{
+ return ((data & LIRC_MODE2_MASK)==LIRC_MODE2_TIMEOUT) ? 1 : 0;
}
static inline int has_repeat(const struct ir_remote* remote)
Index: lirc-0.10.1/lib/irrecord.c
===
--- lirc-0.10.1.orig/lib/irrecord.c
+++ lirc-0.10.1/lib/irrecord.c
@@ -1398,9 +1398,16 @@ enum lengths_status get_lengths(struct l
state->retval = 0;
return STS_LEN_TIMEOUT;
}
+ if (is_timeout(state->data)) {
+ return STS_LEN_AGAIN;
+ }
state->count++;
if (state->mode == MODE_GET_GAP) {
- state->sum += state->data & PULSE_MASK;
+ if (state->sum != 0 || is_pulse(state->data)) {
+ state->sum += state->data & PULSE_MASK;
+ }else{
+ return STS_LEN_AGAIN;
+ }
if (state->average == 0 && is_space(state->data)) {
if (state->data > 10) {
state->sum = 0;
@@ -1472,6 +1479,10 @@ enum lengths_status get_lengths(struct l
state->keypresses = lastmaxcount;
return STS_LEN_AGAIN;
} else if (state->mode == MODE_HAVE_GAP) {
+ if (state->count==1 && is_space(state->data)) {
+ state->count = 0;
+ return STS_LEN_AGAIN;
+ }
if (state->count <= MAX_SIGNALS) {
signals[state->count - 1] = state->data & PULSE_MASK;
} else {
@@ -1510,7 +1521,7 @@ enum lengths_status get_lengths(struct l
/* such long pulses may appear with
* crappy hardware (receiver? / remote?)
*/
- else {
+ else if(is_pulse(state->data)) {
remote->gap = 0;
return STS_LEN_NO_GAP_FOUND;
}
@@ -1811,22 +1822,24 @@ ssize_t raw_read(void* buffer, size_t si
static int raw_data_ok(struct button_state* btn_state)
{
- int r;
+ int r = 0;
int ref;
- if (!is_space(btn_state->data)) {
+ if (is_pulse(btn_state->data)) {
r = 0;
- } else if (is_const()) {
- if (remote.gap > btn_state->sum) {
- ref = (remote.gap - btn_state->sum);
- ref *= (100 - remote.eps);
- ref /= 100;
+ } else if (is_space(btn_state->data)) {
+ if (is_const()) {
+ if (remote.gap > btn_state->sum) {
+ref = (remote.gap - btn_state->sum);
+ref *= (100 - remote.eps);
+ref /= 100;
+ } else {
+ref = 0;
+ }
+ r = btn_state->data > ref;
} else {
- ref = 0;
+ r = btn_state->data > (remote.gap * (100 - remote.eps)) / 100;
}
- r = btn_state->data > ref;
- } else {
- r = btn_state->data > (remote.gap * (100 - remote.eps)) / 100;
}
return r;
}
@@ -1970,7 +1983,7 @@ enum button_status record_buttons(struct
btn_state->data = remote.gap;
}
if (btn_state->count == 0) {
-if (!is_space(btn_state->data)
+if (is_pulse(btn_state->data)
Bug#918360: [Python-apps-team] Bug#918360: pelican: pristine-tar: failed to generate tarball
Control: tag -1 + moreinfo unreproducible On Sat, Jan 5, 2019 at 6:15 AM Geert Stappers wrote: > > Package: pelican > Version: 3.7.1 > > > stappers@paddy:~/src/salsa/pelican > $ pristine-tar checkout pelican_3.7.1.orig.tar.gz > xdelta: expected from file (/tmp/pristine-tar.f_NKRDwoMV/recreatetarball) of > length 2652160 bytes > xdelta: expected from file (/tmp/pristine-tar.f_NKRDwoMV/recreatetarball) of > length 2652160 bytes > xdelta: expected from file (/tmp/pristine-tar.ISkXh5ZYE0/recreatetarball) of > length 2652160 bytes > xdelta: expected from file (/tmp/pristine-tar.aDYb0asTOz/recreatetarball) of > length 2652160 bytes > xdelta: expected from file (/tmp/pristine-tar.aDYb0asTOz/recreatetarball) of > length 2652160 bytes > pristine-tar: Failed to reproduce original tarball. Please file a bug report. > pristine-tar: failed to generate tarball > stappers@paddy:~/src/salsa/pelican > $ pristine-tar checkout pelican_3.7.1+dfsg.orig.tar.gz > xdelta: expected from file (/tmp/pristine-tar.EtCavfD9Nw/recreatetarball) of > length 256 bytes > xdelta: expected from file (/tmp/pristine-tar.EtCavfD9Nw/recreatetarball) of > length 256 bytes > xdelta: expected from file (/tmp/pristine-tar.cr56jbXfJe/recreatetarball) of > length 256 bytes > xdelta: expected from file (/tmp/pristine-tar.Zhv2YE0Mq2/recreatetarball) of > length 256 bytes > xdelta: expected from file (/tmp/pristine-tar.Zhv2YE0Mq2/recreatetarball) of > length 256 bytes > pristine-tar: Failed to reproduce original tarball. Please file a bug report. > pristine-tar: failed to generate tarball > stappers@paddy:~/src/salsa/pelican I can't repro this pristine-tar issue on my end: $ pristine-tar checkout pelican_3.7.1.orig.tar.gz xdelta: expected from file (/tmp/pristine-tar.LM1U7cCS9t/recreatetarball) of length 2652160 bytes xdelta: expected from file (/tmp/pristine-tar.LM1U7cCS9t/recreatetarball) of length 2652160 bytes xdelta: expected from file (/tmp/pristine-tar.rN7_tY18Z4/recreatetarball) of length 2652160 bytes xdelta: expected from file (/tmp/pristine-tar.8GXjLM1JLS/recreatetarball) of length 2652160 bytes pristine-tar: successfully generated pelican_3.7.1.orig.tar.gz $ pristine-tar checkout pelican_3.7.1+dfsg.orig.tar.gz xdelta: expected from file (/tmp/pristine-tar.ydXe1jQGGx/recreatetarball) of length 256 bytes xdelta: expected from file (/tmp/pristine-tar.ydXe1jQGGx/recreatetarball) of length 256 bytes xdelta: expected from file (/tmp/pristine-tar.TUDALYUNdn/recreatetarball) of length 256 bytes xdelta: expected from file (/tmp/pristine-tar._2ygZjICZa/recreatetarball) of length 256 bytes pristine-tar: successfully generated pelican_3.7.1+dfsg.orig.tar.gz I'd be inclined to close this bug unless there's a way to reliably reproduce this (in which case I'd honestly be inclined to just strip out the pristine-tar deltas, but I guess that's another discussion to be had). Regards, Vincent
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
On Mon, 20 Nov 2023 at 11:24:00 +0100, Yannik Sembritzki wrote: > I just had a look at your patch. I think it's the right idea to rather use > what is already there, instead of always creating our own stuff/overwriting > existing /etc/passwd and /etc/nsswitch. > > Thank you! You're welcome :-) > There is only one thing I don't understand: > The patch still uses a random /root-X if a root directory doesn't exist > yet. (As is the case with default initramfs-tools) > I understand that I can fix that with the custom hook, but why not just make > this deterministic by default? > Right now, this creates an extra hurdle for users to find what is breaking > the reproducability, understand the dropbear hook (or find this bug) and > create the custom hook. > Is this really necessary? I'm not keen to use a name containing ‘dropbear’ since ~root doesn't belong to src:dropbear, and creating a generic name has a risk of collision with hooks from other packages (and/or custom hooks). Furthermore, using a deterministic name now with the option to change later might cause trouble to people hardcoding the name (not something recommended of course, but people do that anyway). IMHO the remaining part of the fix belongs to initramfs-tools. If the maintainers want to take care of setting up the root user and its homedir we'll remove the fallback in dropbear-initramfs and just tighten the version number of its dependency. -- Guilhem. signature.asc Description: PGP signature
Bug#1056310: deborphan: [INTL:ro] Translation of "deborphan" to Romanian
Package: deborphan Version: 1.7.35 Severity: wishlist Tags: l10n, patch Dear Maintainer, Please find attached the Romanian translation of the «deborphan» file. A draft has been posted to the debian-l10n-romanian mailing list allowing for review. Please add it to your next package revision. --- Thanks, Remus-Gabriel# deborphan translation to Romanian. # Mesajele în limba românÄ pentru deborphan. # This file is put in the public domain. # # Remus-Gabriel Chelu , 2023. # # Cronologia traducerii fiÈierului âdeborphanâ: # Traducerea iniÈialÄ, fÄcutÄ de R-GC, pentru versiunea deborphan 1.7.35, noi-2023. # Actualizare a traducerii pentru versiunea Y, fÄcutÄ de X, Y(luna-anul). # msgid "" msgstr "" "Project-Id-Version: deborphan 1.7.35\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-08-18 17:34+\n" "PO-Revision-Date: 2023-11-10 10:03+0100\n" "Last-Translator: Remus-Gabriel Chelu \n" "Language-Team: Romanian \n" "Language: ro\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && " "n%100<=19) ? 1 : 2);\n" "X-Generator: Poedit 3.2.2\n" #: src/exit.c:53 #, c-format msgid "" "\n" "The following options are available:\n" msgstr "" "\n" "Sunt disponibile urmÄtoarele opÈiuni:\n" #: src/exit.c:56 #, c-format msgid "-hThis help.\n" msgstr "-hacest ajutor\n" #: src/exit.c:59 #, c-format msgid "-f FILE Use FILE as statusfile.\n" msgstr "-f FIÈIER utilizeazÄ FIÈIERUL ca fiÈier de stare\n" #: src/exit.c:62 #, c-format msgid "-vVersion information.\n" msgstr "-vinformaÈii despre versiune\n" #: src/exit.c:66 #, c-format msgid "-dShow dependencies for packages that have them.\n" msgstr "-dafiÈeazÄ dependenÈele pentru pachetele care le au\n" #: src/exit.c:69 #, c-format msgid "-PShow priority of packages found.\n" msgstr "-PafiÈeazÄ prioritatea pachetelor gÄsite\n" #: src/exit.c:72 #, c-format msgid "-sShow the sections the packages are in.\n" msgstr "-safiÈeazÄ secÈiunile în care se aflÄ pachetele\n" #: src/exit.c:74 #, c-format msgid "--no-show-section Do not show sections.\n" msgstr "--no-show-section nu afiÈeazÄ secÈiunile\n" #: src/exit.c:77 #, c-format msgid "-zShow installed size of packages found.\n" msgstr "-zafiÈeazÄ dimensiunea de instalare a pachetelor gÄsite\n" #: src/exit.c:81 #, c-format msgid "-aCompare all packages, not just libs.\n" msgstr "-acomparÄ toate pachetele, nu doar bibliotecile\n" #: src/exit.c:84 #, c-format msgid "-e LIST Work as if packages in LIST were not installed.\n" msgstr "-e LISTA lucreazÄ ca Èi cum pachetele din LISTÄ nu ar fi instalate\n" #: src/exit.c:87 #, c-format msgid "-HIgnore hold flags.\n" msgstr "-HignorÄ fanioanele de reÈinere/pÄstrare a pachetelor\n" #: src/exit.c:90 #, c-format msgid "Disable checks for `recommends'.\n" msgstr "DezactiveazÄ verificÄrile pentru ârecomandÄriâ.\n" #: src/exit.c:92 #, c-format msgid "Disable checks for `suggests'.\n" msgstr "DezactiveazÄ verificÄrile pentru âsugestiiâ.\n" #: src/exit.c:95 #, c-format msgid "-nDisable checks for `recommends' and `suggests'.\n" msgstr "" "-ndezactiveazÄ verificÄrile pentru ârecomandÄriâ Èi âsugestiiâ\n" #: src/exit.c:98 #, c-format msgid "-p PRIOR Select only packages with priority >= PRIOR.\n" msgstr "-p PRIOR selecteazÄ numai pachetele cu prioritatea >= PRIOR\n" #: src/exit.c:101 #, c-format msgid "--find-config Find \"orphaned\" configuration files.\n" msgstr "" "--find-config gÄseÈte fiÈierele de configurare âorfaneâ\n" #: src/exit.c:105 #, c-format msgid "--libdevel Also search in section \"libdevel\".\n" msgstr "" "--libdevel cautÄ de asemenea în secÈiunea âlibdevelâ\n" #: src/exit.c:109 #, c-format msgid "-A PKGS.. Never report PKGS.\n" msgstr "-A PACHETE nu raporteazÄ niciodatÄ PACHETELE\n" #: src/exit.c:112 #, c-format msgid "-k FILE Use FILE to get/store info about kept packages.\n" msgstr "" "-k FIÈIER utilizeazÄ FIÈIERUL pentru a obÈine/stoca informaÈii despre\n" " pachetele pÄstrate\n" #: src/exit.c:115 #, c-format msgid "-LList the packages that are never reported.\n" msgstr "-L listeazÄ pachetele care nu sunt niciodatÄ raportate\n" #: src/exit.c:118 #, c-format msgid "-R PKGS.. Remove PKGS from the \"keep\" file.\n" msgstr "-R PACHETE eliminÄ PACHETELE din lista de âpÄstrareâ\n" #: src/exit.c:121 #, c-format msgid "-ZRemove all packages from the \"keep\" file.\n" msgstr "-Z eliminÄ toate PACHETELE din lista de âpÄstrareâ\n" #: src/exit.c:125 #, c-format msgid "--df-keep Read debfoster's \"keepers\" file.\n" msgstr "" "--df-keep
Bug#1056309: debomatic: [INTL:ro] Translation of "debomatic" to Romanian
Package: debomatic Version: 0.26 Severity: wishlist Tags: l10n, patch Dear Maintainer, Please find attached the Romanian translation of the «debomatic» file. A draft has been posted to the debian-l10n-romanian mailing list allowing for review. Please add it to your next package revision. --- Thanks, Remus-Gabriel# Romanian translation for debomatic # Traducerea mesajelor de «debomatic» în limba românÄ. # Copyright (c) 2009 Rosetta Contributors and Canonical Ltd 2009. # Copyright © 2023 Free Software Foundation, Inc. # This file is distributed under the same license as the debomatic package. # # Lucian Adrian Grijincu , 2010. # Remus-Gabriel Chelu , 2023. # # Cronologia traducerii fiÈierului âdebomaticâ: # Traducerea iniÈialÄ, fÄcutÄ de LAG, pentru versiunea debomatic 0.8 "daking" (2010-02-04), oct-2010. # Actualizare a traducerii pentru versiunea 0.26 "melting" (2022-07-10), fÄcutÄ de R-GC, noi-2023. # Actualizare a traducerii pentru versiunea Y, fÄcutÄ de X, Y(luna-anul). # msgid "" msgstr "" "Project-Id-Version: debomatic 0.26\n" "Report-Msgid-Bugs-To: FULL NAME \n" "POT-Creation-Date: 2016-11-08 11:18+0100\n" "PO-Revision-Date: 2023-11-09 10:51+0100\n" "Last-Translator: Remus-Gabriel Chelu \n" "Language-Team: Romanian \n" "Language: ro\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Launchpad-Export-Date: 2021-01-26 16:43+\n" "X-Generator: Poedit 3.2.2\n" #: Debomatic/build.py:55 #, python-format msgid "Build already scheduled for package %(package)s_%(version)s in %(dist)s" msgstr "Construire deja programatÄ pentru pachetul %(package)s_%(version)s în %(dist)s" #: Debomatic/build.py:75 #, python-format msgid "Skipping removal of file %s" msgstr "Se omite eliminarea fiÈierului %s" #: Debomatic/build.py:117 #, python-format msgid "Distribution %s is disabled" msgstr "DistribuÈia %s este dezactivatÄ" #: Debomatic/build.py:161 #, python-format msgid "Building %s" msgstr "Se construieÈte %s" #: Debomatic/build.py:232 Debomatic/build.py:532 Debomatic/build.py:540 #: Debomatic/build.py:229 Debomatic/build.py:528 Debomatic/build.py:536 #, python-format msgid "Build of %s failed" msgstr "Construirea lui %s a eÈuat" #: Debomatic/build.py:235 Debomatic/build.py:232 #, python-format msgid "Build of %s successful" msgstr "Construirea lui %s a fost realizatÄ cu succes" #: Debomatic/build.py:242 Debomatic/build.py:239 #, python-format msgid "Build of %s complete" msgstr "Construirea lui %s este completÄ" #: Debomatic/build.py:273 Debomatic/build.py:270 #, python-format msgid "Requesting URL %s" msgstr "Se solicitÄ adresa URL %s" #: Debomatic/build.py:291 Debomatic/build.py:366 Debomatic/build.py:518 #: Debomatic/build.py:288 Debomatic/build.py:363 Debomatic/build.py:514 #, python-format msgid "Bad .changes file: %s" msgstr "FiÈier .changes greÈit: %s" #: Debomatic/build.py:298 Debomatic/build.py:370 Debomatic/build.py:374 #: Debomatic/build.py:295 Debomatic/build.py:367 Debomatic/build.py:371 #, python-format msgid "Distribution %s not configured" msgstr "DistribuÈia %s nu este configuratÄ" #: Debomatic/build.py:302 Debomatic/build.py:319 Debomatic/build.py:299 #: Debomatic/build.py:316 #, python-format msgid "Downloading missing %s" msgstr "Se descarcÄ â%sâ lipsÄ" #: Debomatic/build.py:311 Debomatic/build.py:331 Debomatic/build.py:504 #: Debomatic/build.py:516 Debomatic/build.py:308 Debomatic/build.py:328 #: Debomatic/build.py:500 Debomatic/build.py:512 #, python-format msgid "File %s added" msgstr "FiÈierul %s a fost adÄugat" #: Debomatic/build.py:313 Debomatic/build.py:333 Debomatic/build.py:310 #: Debomatic/build.py:330 #, python-format msgid "Unable to fetch %s" msgstr "Nu se poate prelua %s" #: Debomatic/build.py:349 Debomatic/build.py:346 #, python-format msgid "%(mapped)s mapped as %(mapper)s" msgstr "%(mapped)s alocat ca %(mapper)s" #: Debomatic/build.py:360 Debomatic/build.py:510 Debomatic/build.py:357 #: Debomatic/build.py:506 #, python-format msgid "Unable to open %s" msgstr "Nu s-a putut deschide %s" #: Debomatic/build.py:383 Debomatic/build.py:380 #, python-format msgid "File %s removed" msgstr "FiÈierul %s a fost eliminat" #: Debomatic/build.py:414 Debomatic/build.py:411 #, python-format msgid "schroot profile %s not found" msgstr "profilul schroot %s nu a fost gÄsit" #: Debomatic/build.py:428 Debomatic/build.py:425 #, python-format msgid "Creating chroot %(dist)s-%(arch)s-debomatic" msgstr "Se creeazÄ chroot-ul %(dist)s-%(arch)s-debomatic" #: Debomatic/build.py:452 Debomatic/build.py:449 #, python-format msgid "Failed creating %(dist)s-%(arch)s-debomatic" msgstr "Crearea chroot-ului %(dist)s-%(arch)s-debomatic a eÈuat" #: Debomatic/build.py:459 Debomatic/build.py:456 msgid "Unable to launch sbuild-createchroot" msgstr "Nu s-a putut lansa «sbuild-createchroot»" #: Debomatic/build.py:505 Debomatic/commands.py:40 Debomatic/build.py:501 #, python-format msgid
Bug#1056308: transition: wireshark
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I'd like to update wireshark in unstable. The only reverse dependency to be rebuilt is libvirt [1]. Libvirt fails to rebuild for me locally on an Ubuntu system in an unstable schroot environment with and without wireshark with the same test error: ... --- stderr --- TEST: virnetsockettest Cannot identify IPv4/6 availability ... Summary of Failures: 124/173 libvirt:bin / virnetsockettestFAIL 0.05s exit status 1 Ok: 171 Expected Fail: 0 Fail: 1 Unexpected Pass:0 Skipped:1 Timeout:0 ... I believe libvirt will build fine with the updated wireshark package on the buildds. Thank you, Balint [1] https://release.debian.org/transitions/html/auto-wireshark.html
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Mon, Nov 20, 2023 at 10:59:02AM +0100, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: >... > Not sure, if we need an updated breaks statement. >... Right now the autopkgtests block zlib migration to testing since they test zlib/unstable with texlive-binaries/testing - this is permitted by the dependencies. And this is not just a test issue: On Sun, Nov 19, 2023 at 01:54:02PM +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: >... > > And it also might affects users directly, without proper dependencies > > e.g. a bookworm -> trixie upgrade might end up with the following order > > (among many other things happening during the upgrade): > > 1. zlib gets upgraded > > 2. the tex-common trigger runs > > 3. texlive-bin gets upgraded > > If this is permitted by the dependencies, then step 2 must not fail. > > I'd rather expect that the triggers run at the end of the setup process, > i.e. after all packages replaced their files. At least this was the original > ideal behind them IIRC. The idea is to avoid unnecessary duplicate commands, but more than once might be required. And when upgrading to a new stable there are several cycles where triggers run at the end (you might not notice since the package manager takes care of it). On a bookworm -> trixie upgrade the man-db trigger might run 5 or 10 times instead of 1000 packages each executing the command, but it will definitely run more than once. If one of the dependencies of texlive-binaries Pre-Depends on zlib1g, this might be sufficient to ensure that all pending triggers are running after the upgrade of zlib1g and before the upgrade ot texlive-binaries. > Hilmar cu Adrian
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
Hi Guilhem, I just had a look at your patch. I think it's the right idea to rather use what is already there, instead of always creating our own stuff/overwriting existing /etc/passwd and /etc/nsswitch. Thank you! There is only one thing I don't understand: The patch still uses a random /root-X if a root directory doesn't exist yet. (As is the case with default initramfs-tools) I understand that I can fix that with the custom hook, but why not just make this deterministic by default? Right now, this creates an extra hurdle for users to find what is breaking the reproducability, understand the dropbear hook (or find this bug) and create the custom hook. Is this really necessary? Best regards Yannik
Bug#1055876: lastpass-cli: lpass login fails with "Error: SSL peer certificate or SSH remote key was not OK."
Domenico Andreoli wrote: > As far as I can see the version in Bookworm is still severely broken > and unusable; it deserves at least a bug to document its state. Indeed; bookworm should either be updated or the package removed. I've filed a proposed update bug here: https://bugs.debian.org/1056307 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1056065: transition: spdlog
Hi Sebastian, On 2023-11-18 14:36, Sebastian Ramacher wrote: spdlog's autopkgtest fail, though: https://ci.debian.net/data/autopkgtest/testing/amd64/s/spdlog/39983394/log.gz Could you please take a look? Apparently spdlog needs catch2 >= 3.0.0. I have just added the versioned depends and uploaded. Best, Andrius
Bug#1056307: bookworm-pu: package lastpass-cli/1.3.7-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Dear stable release managers,
Please consider lastpass-cli (1.3.7-1+deb12u1) for bookworm:
lastpass-cli (1.3.7-1+deb12u1) bookworm; urgency=medium
.
* Upload latest upstream version to fix compatability with Lastpass's
SSL keys. (Closes: #1055876)
Currently, lastpass-cli is completely non-functioning in bookworm, so
it should either be updated or removed.
The full debdiff is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/debian/changelog b/debian/changelog
index 800751f..68e0043 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,42 @@
+lastpass-cli (1.3.7-1+deb12u1) bookworm; urgency=medium
+
+ * Upload latest upstream version to fix compatability with Lastpass's
+SSL keys. (Closes: #1055876)
+
+ -- Chris Lamb Mon, 20 Nov 2023 10:14:54 +
+
+lastpass-cli (1.3.7-1) unstable; urgency=medium
+
+ * New upstream release. (Closes: #1055876)
+ * Drop 0001-Fix-FTBFS-with-GCC-10.0.patch; applied upstream.
+
+ -- Chris Lamb Mon, 13 Nov 2023 12:40:41 +
+
+lastpass-cli (1.3.6-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Refresh patches.
+
+ -- Chris Lamb Sat, 09 Sep 2023 09:52:20 -0700
+
+lastpass-cli (1.3.5-2) unstable; urgency=medium
+
+ * Always use the Debian version number. (Closes: #1051218)
+
+ -- Chris Lamb Tue, 05 Sep 2023 10:12:30 -0700
+
+lastpass-cli (1.3.5-1) unstable; urgency=medium
+
+ * New upstream release. (Closes: #1050973)
+
+ -- Chris Lamb Thu, 31 Aug 2023 16:37:52 -0700
+
+lastpass-cli (1.3.4-2) unstable; urgency=medium
+
+ * Also clean test/.lpass directory. (Closes: #1048723)
+
+ -- Chris Lamb Tue, 22 Aug 2023 13:44:44 -0700
+
lastpass-cli (1.3.4-1) unstable; urgency=medium
* New upstream release.
diff --git a/.gitignore b/.gitignore
index 495a746..9383e25 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@ version.h
# IDE
/.idea
+/.vs
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 21c854d..e953cee 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,13 @@
+# Vesion 1.3.7
+* Add support for reading encrypted URLs (Tibor Komlossy)
+* Fix GCC 10 compatibility issue #532 (Tibor Komlossy)
+
+# Version 1.3.6
+* Fix version (Béla Ormos)
+
+# Version 1.3.5
+* Updating certificate hashes (Béla Ormos)
+
# Version 1.3.4
* Updating post parameter (Gergely Der)
diff --git a/LASTPASS-VERSION-GEN b/LASTPASS-VERSION-GEN
index d9b0f48..8f75701 100755
--- a/LASTPASS-VERSION-GEN
+++ b/LASTPASS-VERSION-GEN
@@ -4,7 +4,7 @@
# You can find the original at
https://github.com/git/git/blob/master/GIT-VERSION-GEN
LPVF=version.h
-DEF_VER=v1.3.4.GIT
+DEF_VER=v1.3.7.GIT
LF='
'
diff --git a/blob.c b/blob.c
index 69d9f44..f95305f 100644
--- a/blob.c
+++ b/blob.c
@@ -104,6 +104,7 @@ void account_free_contents(struct account *account)
free(account->note);
free(account->name_encrypted);
free(account->group_encrypted);
+ free(account->url_encrypted);
free(account->username_encrypted);
free(account->password_encrypted);
free(account->note_encrypted);
@@ -320,6 +321,10 @@ static int read_boolean(struct chunk *chunk)
return item.data[0] == '1';
}
+static bool check_next_entry_encrypted(struct chunk *chunk) {
+ return (chunk->data + sizeof(uint32_t))[0] == '!';
+}
+
#define entry_plain_at(base, var) do { \
char *__entry_val__ = read_plain_string(chunk); \
if (!__entry_val__) \
@@ -360,6 +365,9 @@ static struct account *account_parse(struct chunk *chunk,
const unsigned char ke
entry_plain(id);
entry_crypt(name);
entry_crypt(group);
+ if (check_next_entry_encrypted(chunk))
+ entry_crypt(url);
+ else
entry_hex(url);
entry_crypt(note);
entry_boolean(fav);
diff --git a/blob.h b/blob.h
index d6c480a..ab6c32d 100644
--- a/blob.h
+++ b/blob.h
@@ -59,7 +59,7 @@ struct account {
char *name, *name_encrypted;
char *group, *group_encrypted;
char *fullname;
- char *url;
+ char *url, *url_encrypted;
char *username, *username_encrypted;
char *password, *password_encrypted;
char *note, *note_encrypted;
diff --git a/debian/control b/debian/control
index 64bb52d..5440be8 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
libxml2-dev,
pkg-config,
xsltproc,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
Homepage: https://github.com/lastpass/lastpass-cli
Vcs-Git: https://salsa.debian.org/lamby/pkg-lastpass-cli.git
Vcs-Browser: https://salsa.debian.org/lamby/pkg-lastpass-cli
diff --git a/debian/patches/0001-Fix-FTBFS-with-GCC-10.0.patch
b/debian/patches/0001-Fix-FTBFS-with-GCC-10.0.patch
deleted file mode 100644
index 4cef68b..000
---
Bug#1051243: PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3)
The previous error messages showed that the locale was not configured. I configured the locale but the problem persists but now with an additional PANIC: /tmp/fmtutil.kYG8CZ8c No pages of output. Transcript written on pdfetex.log. fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/pdftex/pdfetex.log fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/pdfetex.fmt installed. fmtutil [INFO]: --- remaking dvilualatex with luatex fmtutil: running `luatex -ini -jobname=dvilualatex -progname=dvilualatex dvilualatex.ini' ... PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) Aborted fmtutil [ERROR]: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini
Bug#1056306: haskell-hadrian: makes ghc FTBFS on hurd-i386
Source: haskell-hadrian Version: 9.4.7-3 Severity: important Tags: patch Since version 9.4.7 and the switch to using Hadrian, ghc fails to build on hurd-i386. This is because of a confusion between "gnu" and "hurd". The attached patches fix the confusion. One is already submitted upstream, the other is already fixed in newer upstream versions. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11624 Index: ghc-9.4.7/hadrian/src/Hadrian/Haskell/Cabal.hs === --- ghc-9.4.7.orig/hadrian/src/Hadrian/Haskell/Cabal.hs +++ ghc-9.4.7/hadrian/src/Hadrian/Haskell/Cabal.hs @@ -71,4 +71,5 @@ cabalOsString :: String -> String cabalOsString "mingw32" = "windows" cabalOsString "darwin" = "osx" cabalOsString "solaris2" = "solaris" +cabalOsString "gnu" = "hurd" cabalOsString other = other Also applies in 9.6.x Can be dropped with 9.8.1 Index: ghc-9.4.7/hadrian/src/Oracles/Setting.hs === --- ghc-9.4.7.orig/hadrian/src/Oracles/Setting.hs +++ ghc-9.4.7/hadrian/src/Oracles/Setting.hs @@ -273,7 +273,7 @@ anyHostOs = matchSetting HostOs isElfTarget :: Action Bool isElfTarget = anyTargetOs [ "linux", "freebsd", "dragonfly", "openbsd", "netbsd", "solaris2", "kfreebsdgnu" -, "haiku", "linux-android" +, "gnu", "haiku", "linux-android" ] -- | Check whether the host OS supports the @-rpath@ linker option when @@ -282,7 +282,7 @@ isElfTarget = anyTargetOs -- TODO: Windows supports lazy binding (but GHC doesn't currently support -- dynamic way on Windows anyways). hostSupportsRPaths :: Action Bool -hostSupportsRPaths = anyHostOs ["linux", "darwin", "freebsd"] +hostSupportsRPaths = anyHostOs ["linux", "darwin", "freebsd", "gnu"] -- | Check whether the target supports GHCi. ghcWithInterpreter :: Action Bool
Bug#1056305: ghc: FTBFS on hurd-i386
Package: ghc Version: 9.4.7-1 Severity: important Tags: patch Hello, Since version 9.4.7 and the switch to using Hadrian, ghc fails to build on hurd-i386. This is because of a confusion between "gnu" and "hurd". The attached patches fix the confusion. Some of them have just been commited upstream, others are already fixed in newer upstream versions. I will submit the hadrian patches to the haskell-hadrian package too. (they are needed in ghc to be able to build with the pkg.ghc.nohadrian profile until they get applied to the haskell-hadrian package) Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ghc depends on: ii dpkg1.22.1 ii gcc 4:13.2.0-1 ii libbsd-dev 0.11.7-4 ii libc6 2.37-12 ii libc6-dev 2.37-12 ii libffi-dev 3.4.4-1 ii libffi8 3.4.4-1 ii libgmp-dev 2:6.3.0+dfsg-2 ii libgmp102:6.3.0+dfsg-2 ii libncurses-dev 6.4+20231016-1 ii libtinfo6 6.4+20231016-1 ghc recommends no packages. Versions of packages ghc suggests: pn ghc-doc pn ghc-prof pn haskell-doc ii llvm-13 1:13.0.1-13 ii perl 5.36.0-9 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. https://github.com/haskell/cabal/pull/9434 Index: ghc-9.4.7/libraries/Cabal/Cabal/src/Distribution/Simple/GHC/Internal.hs === --- ghc-9.4.7.orig/libraries/Cabal/Cabal/src/Distribution/Simple/GHC/Internal.hs +++ ghc-9.4.7/libraries/Cabal/Cabal/src/Distribution/Simple/GHC/Internal.hs @@ -609,6 +609,7 @@ ghcOsString :: OS -> String ghcOsString Windows = "mingw32" ghcOsString OSX = "darwin" ghcOsString Solaris = "solaris2" +ghcOsString Hurd= "gnu" ghcOsString other = prettyShow other -- | GHC's rendering of its platform and compiler version string as used in https://github.com/haskell/cabal/pull/9441 Index: ghc-9.4.7/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs === --- ghc-9.4.7.orig/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs +++ ghc-9.4.7/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs @@ -1792,7 +1792,7 @@ getRPaths lbi clbi | supportRPaths hostO supportRPaths Android = False supportRPaths Ghcjs = False supportRPaths Wasi= False -supportRPaths Hurd= False +supportRPaths Hurd= True supportRPaths (OtherOS _) = False -- Do _not_ add a default case so that we get a warning here when a new OS -- is added. Index: ghc-9.4.7/libraries/Cabal/Cabal/src/Distribution/Simple/GHCJS.hs === --- ghc-9.4.7.orig/libraries/Cabal/Cabal/src/Distribution/Simple/GHCJS.hs +++ ghc-9.4.7/libraries/Cabal/Cabal/src/Distribution/Simple/GHCJS.hs @@ -1537,7 +1537,7 @@ getRPaths lbi clbi | supportRPaths hostO supportRPaths Android = False supportRPaths Ghcjs = False supportRPaths Wasi= False -supportRPaths Hurd= False +supportRPaths Hurd= True supportRPaths (OtherOS _) = False -- Do _not_ add a default case so that we get a warning here when a new OS -- is added. Also applies in 9.6.x Can be dropped with 9.8.1 Index: ghc-9.4.7/libraries/ghc-boot/GHC/BaseDir.hs === --- ghc-9.4.7.orig/libraries/ghc-boot/GHC/BaseDir.hs +++ ghc-9.4.7/libraries/ghc-boot/GHC/BaseDir.hs @@ -23,7 +23,7 @@ import System.FilePath #if defined(mingw32_HOST_OS) import System.Environment (getExecutablePath) -- POSIX -#elif defined(darwin_HOST_OS) || defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(openbsd_HOST_OS) || defined(netbsd_HOST_OS) +#elif defined(darwin_HOST_OS) || defined(linux_HOST_OS) || defined(freebsd_HOST_OS) || defined(openbsd_HOST_OS) || defined(netbsd_HOST_OS) || defined(hurd_HOST_OS) import System.Environment (getExecutablePath) #endif @@ -52,7 +52,7 @@ getBaseDir = Just .
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
On Mon, 20 Nov 2023 at 10:42:30 +0100, Yannik Sembritzki wrote:
> Would you be open to a two step approach like this:
>
> 1. fix the reproducibility bug
> 2. improve the root directory creation process (I can create another bug to
> track this)
Just pushed
https://salsa.debian.org/debian/dropbear/-/commit/1c709e951d97a132a9d4f3de4b9cc406a83e0b64
,
~root will now be reused if the root user is already set up. Ideally
the latter should be done by initramfs-tools itself, but in the meantime
copyping the enclosed hook into /usr/share/initramfs-tools/hooks should
solve the issue (once 2022.83-3 lands in sid).
--
Guilhem.
#!/bin/sh
PREREQ=""
prereqs() {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
home="/rootuser"
echo "root:*:0:0::$home:/bin/sh" >"$DESTDIR/etc/passwd"
mkdir -m0700 "$DESTDIR$home"
signature.asc
Description: PGP signature
Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved
Control: severity -1 normal Control: tags -1 moreinfo On Mon, 20 Nov 2023 12:36:51 +0530 Pirate Praveen wrote: > It misses a dependency on openvpn-systemd-resolved and on boomworm it > was working after installing it. I do not have this installed however riseup-vpn works for me without any issues. Others who have tested this package on bookworm in the past also did not have any such issues. I tried with systemd-resolved installed without openvpn-systemd-resolved install - no problems observed. > But on mobian trixie, which has > systemd-resolved installed by default (through mobian-base), dns > resolution fails when riseup vpn is connected. I do not have a device to try out mobian. I tried it on debian trixie/testing with openvpn-system-resolved and I do not see any such issue. > ;; communications error to 127.0.0.53#53: timed out > ;; communications error to 127.0.0.53#53: timed out > ;; no servers could be reached OTOH, this log has very superficial info and is not helpful into debugging if there's even anything wrong with riseup-vpn. This maybe a setup/configuration issue for your system. I did find a similar issue on the systemd repository itself[1] and the fix was to add in a "DNS=" entry in resolved.conf. Can you try this and report back? Could you also check this on a different network connection? [1]: https://github.com/systemd/systemd/issues/25397 Best, Nilesh signature.asc Description: PGP signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 20.11.2023 01:13, Adrian Bunk wrote: Hi, I just noticed that we had this issue already 13 years ago. [2] And from then zlib1g still has the Breaks: texlive-binaries (<< 2009-12) that will also require updating again. No, that's younger: zlib (1:1.2.6.dfsg-2) unstable; urgency=low * Break texlive-binaries before 2009-12 due to gzeof() behaviour change (closes: #659681). -- Mark Brown Thu, 23 Feb 2012 23:28:27 + Not sure, if we need an updated breaks statement. Anyway, I'll ping Tiago again, if the test can be removed at all- Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056117: meson: generates non-determinstic .pkgconfig files
forwarded 1056117 https://github.com/mesonbuild/meson/pull/12528 thanks Jussi Pakkanen wrote: > Please file all changes like these directly upstream. The Meson > packaging prohibits patches that alter functionality. Sure thing. I've done that here: https://github.com/mesonbuild/meson/pull/12528 (Although do note that I've suggested a slightly less intrusive patch for reasons mentioned in the pull request.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1056304: lualatex needs to be rebuilt against zlib 1.3
Control: reassign -1 texlive-binaries Control: block -1 by 1056204 Control: severity -1 grave Control: forcemerge -1 1056183 On 20.11.2023 10:29, Eric Marsden wrote: Hi, % lualatex PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) zsh: IOT instruction lualatex % lualatex --credits This is LuaHBTeX, Version 1.17.0 (TeX Live 2023/Debian) The LuaTeX team is Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso. Reported a few times already, merging. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
of course we can steadily move on, no problem. So now we move to VLAN level?
BR
Peter
-Original Message-
From: Daniel Gröber
Sent: sobota 18. novembra 2023 3:43
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
On Mon, Nov 13, 2023 at 09:40:46AM +, peter.gasparo...@orange.com wrote:
> In the meantime, I was stubborn to find a solution to what I need in
> order to progress and MACVLAN tech actually delivered it (private mode
> enough),
I used to love macvlan too but now I do L3 instead ;P
> something newer than VETH tech what I could read about, and it's just
> perfect avoiding bridge itself. So no problem to cooperate on this
> fix, I will be glad, just it can get lower priority on your side if
> you even attributed it some
I'd be happy to still track this bug down but I need you to investigate the
behaviour in your environment. If you've torn down the lab already we can also
just call it quits.
If you do want to continue some questions are still pending, see quoted below.
> On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > 1) As was reported, foreign external world MAC@ does not pass into
> > network namespace, just external border point "vlan199"
>
> How did you check this?
>
> > 2) now collecting data for you, honestly I don’t see external mac
> > address on "inet-br" object, so my previous statement was incorrect..
> > {ossibly I might mixed this up with another "labinet-br" (working in
> > its limited
> > scope) which is IP-defined, while "inet-br" in question is not.
> >
> > 3) so question is, if the MACs learnt via vlan199 are supposed to be
> > paired (displayed) with "inet-br" object and all way up into NS
>
> I want to make sure we're on the same page, how do you check if the MAC is
> reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
> this will tell you whether ARP is even reaching the NS or not.
>
> Something simple like
>
> $ tcpdump -enli $IFACE 'arp or icmp'
>
> optionally you can filter by MAC (`ether host` in pcap-filter speak):
>
> $ tcpdump -enli $IFACE ('arp or icmp) and ether host
> aa:00:00:00:00:01
>
> Oh and one last thing: please double and tripple check that a firewall isn't
> interfering.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Bug#1053707: plasma-nm: after upgrade of network-manager shows "no available connection", networking works
A bypass could be to restart manually the systray but I don't know how to do that. Somebody can explain to me ? Thanks -- Francois Mescam
Bug#1056304: lualatex needs to be rebuilt against zlib 1.3
Package: texlive-latex-base Version: 2023.20231007-1 Severity: important % lualatex PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) zsh: IOT instruction lualatex % lualatex --credits This is LuaHBTeX, Version 1.17.0 (TeX Live 2023/Debian) The LuaTeX team is Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso. LuaHBTeX merges and builds upon (parts of) the code from these projects: tex : Donald Knuth etex : Peter Breitenlohner, Phil Taylor and friends omega : John Plaice and Yannis Haralambous aleph : Giuseppe Bilotta pdftex: Han The Thanh and friends kpathsea : Karl Berry, Olaf Weber and others lua : Roberto Ierusalimschy, Waldemar Celes and Luiz Henrique de Figueiredo metapost : John Hobby, Taco Hoekwater, Luigi Scarso, Hans Hagen and friends pplib : Paweł Jackowski fontforge : George Williams (partial) luajit: Mike Pall (used in LuajitTeX) Compiled with libharfbuzz 8.0.1; using 8.0.1 Compiled with libpng 1.6.40; using 1.6.40 Compiled with lua version 5.3.6 Compiled with mplib version 2.02 Compiled with zlib 1.2.13; using 1.3 Development id: 7581 Packages zlib1g and zlib1g-dev are at version 1.3.dfsg-2 (from unstable).
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
Hi Guilhem, I agree, the concept of dropbear-initramfs creating the root directory and /etc/passwd also seemed a bit weird to me. However, the intended purpose of my patch was to first and foremost fix the reproducibility bug, and not change the general process of root directory creation. Would you be open to a two step approach like this: 1. fix the reproducibility bug 2. improve the root directory creation process (I can create another bug to track this) Best regards Yannik On 20.11.23 09:43, Guilhem Moulin wrote: Control: retitle -1 dropbear-initramfs makes initramfs non-reproducible Control: severity -1 wishlist Control: tag -1 - patch Hi, On Sun, 19 Nov 2023 at 15:45:22 +0100, Yannik Sembritzki wrote: One solution would be to simply always use /root-dropbear-initramfs. I'm not in favour of that solution, as ~root doesn't belong to dropbear-initramfs. I think it would be best if the root user and its homedir were created by initramfs-tools itself; failing that it could be created by another directory hook outside src:dropbear (possibly your own custom hook), and dropbear-initramfs's hook could use that.
Bug#1051243: This affects the build of the pspp package
Hi all, i noticed a failure in our CI pipeline for pspp probably due to this bug. The problem occurs when I try to install "apt install texlive-plain-generic“. The install fails with …. Processing triggers for tex-common (6.18) … locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.S3jngCrK Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common E: Sub-process /usr/bin/dpkg returned an error code (1) …. In /tmp/fmtutil.S3jngCrk the following error messages are shown: /tmp/fmtutil.S3jngCrk ... No pages of output. Transcript written on latex.log. fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/pdftex/latex.log fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/latex.fmt installed. fmtutil [ERROR]: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini
Bug#1055035: ftp.debian.org: missing links on mirrors for contrib and non-free-firmware
On 29/10/23 at 21:37 +0100, Lucas Nussbaum wrote: > Package: ftp.debian.org > Severity: important > > Hi, > > On 2023-10-17, slurm-wlm-contrib was uploaded to bookworm-security. > Apparently it was the first ever security upload to contrib, and I > noticed there's a missing link in /pool from contrib to updates/contrib > (there are such links for main and non-free). The same issue is also > present for non-free-firmware. > > See https://deb.debian.org/debian-security/pool/ or > http://security.debian.org/debian-security/pool/ > > The UDD patches importer chokes on this, that's how I noticed. FYI: this is still an issue, but I worked-around this in UDD (by using the fact that the package is also available in the 'debian' archive (in bookworm-pu) Lucas
Bug#1055876: lastpass-cli: lpass login fails with "Error: SSL peer certificate or SSH remote key was not OK."
Control: reopen 1055876 Control: found 1.3.4-1 Control: fixed 1.3.7-1 Hi, As far as I can see the version in Bookworm is still severely broken and unusable; it deserves at least a bug to document its state. Thanks! Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1056165: google.protobuf stubs missing?
Control: tags -1 +confirmed On Fri, 17 Nov 2023 21:22:55 -0500 David Mandelberg wrote: > python3-typeshed has python3-types-protobuf in its Provides, so I assume > it's supposed to provide types for google.protobuf? But I don't actually > see any stubs for that package, and mypy gives this error: Looks like the overlapping namespaces with types_google_cloud is the cause: > WARNING: Target directory /<>/debian/python3-typeshed/usr/lib/python3/dist-packages/google-stubs already exists. Specify --upgrade to force replacement. ( From https://buildd.debian.org/status/fetch.php?pkg=typeshed=all=0.0%7Egit2023.6764465-2=1699968002=0 ) To fix this will require changes to https://salsa.debian.org/python-team/packages/typeshed/-/blob/debian/unstable/debian/install_stubs.py Perhaps a separate install_root for each package, and then merge them together at the end in debian/python3-typeshed ? -- Michael R. Crusoe OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1052580: swi-prolog: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Hi Vladimir, Пн 20 ноя 2023 @ 09:09 Vladimir Petko : > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/debian/swi-prolog/-/merge_requests/3 In fact, this was fixed upstream (but the fix is still not entered swipl stable repository) by bumping Java compatibily to 8. Please, see this [commit]. I'll look into it soon. [commit] https://github.com/SWI-Prolog/packages-jpl/commit/c05e51bae51511fa6d69b9b6cca25bbaad4ee084 Cheers! Lev
Bug#1056048: Acknowledgement (Memory leak in dcm2json)
As pointed out by upstream, one must export the following: You should set the environment variable ICONV_MAX_REUSE to zero before running such tests: export ICONV_MAX_REUSE=0 valgrind --leak-check=full ... Which gives now the reduced set of leaks: % valgrind --leak-check=full --show-leak-kinds=all dcm2json charsettests/SCSARAB output.json ==1928491== Memcheck, a memory error detector ==1928491== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1928491== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1928491== Command: dcm2json charsettests/SCSARAB output.json ==1928491== ==1928491== ==1928491== HEAP SUMMARY: ==1928491== in use at exit: 842 bytes in 2 blocks ==1928491== total heap usage: 80,067 allocs, 80,065 frees, 2,124,652 bytes allocated ==1928491== ==1928491== 26 bytes in 1 blocks are still reachable in loss record 1 of 2 ==1928491==at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==1928491==by 0x4E037F9: strdup (strdup.c:42) ==1928491==by 0x4F5C7F1: UnknownInlinedFun (citrus_mapper.c:119) ==1928491==by 0x4F5C7F1: _citrus_csmapper_open.constprop.0 (citrus_csmapper.c:388) ==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186) ==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225) ==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283) ==1928491==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared (citrus_iconv_std.c:382) ==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201) ==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265) ==1928491==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349) ==1928491==by 0x4F59117: _iconv_open (oficonv_iconv.c:107) ==1928491==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337) ==1928491==by 0x4AE71E2: OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) (ofchrenc.cc:785) ==1928491==by 0x49B5F63: DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions() (dcspchrs.cc:338) ==1928491==by 0x49B6797: DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) (dcspchrs.cc:189) ==1928491==by 0x498F5A6: DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, unsigned long, bool) (dcitem.cc:4403) ==1928491==by 0x498CB96: DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long, bool) (dcitem.cc:4442) ==1928491==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465) ==1928491== ==1928491== 816 bytes in 1 blocks are still reachable in loss record 2 of 2 ==1928491==at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==1928491==by 0x4F5C7DD: UnknownInlinedFun (citrus_mapper.c:114) ==1928491==by 0x4F5C7DD: _citrus_csmapper_open.constprop.0 (citrus_csmapper.c:388) ==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186) ==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225) ==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283) ==1928491==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared (citrus_iconv_std.c:382) ==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201) ==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265) ==1928491==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349) ==1928491==by 0x4F59117: _iconv_open (oficonv_iconv.c:107) ==1928491==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337) ==1928491==by 0x4AE71E2: OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) (ofchrenc.cc:785) ==1928491==by 0x49B5F63: DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions() (dcspchrs.cc:338) ==1928491==by 0x49B6797: DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) (dcspchrs.cc:189) ==1928491==by 0x498F5A6: DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, unsigned long, bool) (dcitem.cc:4403) ==1928491==by 0x498CB96: DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long, bool) (dcitem.cc:4442) ==1928491==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465) ==1928491==by 0x10C7D3: main (dcm2json.cc:281) ==1928491== ==1928491== LEAK SUMMARY: ==1928491==definitely lost: 0 bytes in 0 blocks ==1928491==indirectly lost: 0 bytes in 0 blocks ==1928491== possibly lost: 0 bytes in 0 blocks ==1928491==still reachable: 842 bytes in 2 blocks ==1928491== suppressed: 0
Bug#1056303: pg_createcluster destroys data directory under certain conditions
Package: postgresql-common Version: 248 Severity: critical When I tried to use "pg_createcluster" to configure my pre-existing PostgreSQL data directory with a new Debian install, it deleted the whole cluster with all databases instead. (This serious data loss justifies "severity critical" according to https://www.debian.org/Bugs/Developer#severities) Steps to reproduce: pg_createcluster 15 test cp /etc/postgresql/15/test/postgresql.conf /var/lib/postgresql/15/test/ rm -r /etc/postgresql/15/test pg_createcluster 15 test This creates a new cluster just for the demo, then deletes the configuration directory, after copying the postgresql.conf to the data directory. I expect the second "pg_createcluster" call to find the existing data directory and configure it; and it tries to do so indeed: Configuring already existing cluster (configuration: /etc/postgresql/15/test, data: /var/lib/postgresql/15/test, owner: 103:111) After it finds and moves a "postgresql.conf", it however fails to find "pg_hba.conf" Error: move_conffile: required configuration file /var/lib/postgresql/15/test/pg_hba.conf does not exist This fails the whole operation, and apparently, "pg_createcluster" tries to roll back by invoking "pg_dropcluster 15 test 2>/dev/null", destroying all pre-existing data. If "postgresql.conf" does not exist (or is empty), "pg_dropcluster" is not invoked.
Bug#1056302: FreeBSD/iconv: ISO 2022 IR 13\ISO 2022 IR 87
Source: dcmtk Version: 3.6.8~git20231027.1549d8c-2 Somewhat related to #988644. Steps: % curl -O https://dclunie.com/images/charset/charsettests.20070405.tar.bz2 % tar xf charsettests.20070405.tar.bz2 % cp charsettests/SCSH32 new.dcm % dcmodify -i "0018,1020=123\456" new.dcm Gives % dcmdump +U8 new.dcm | grep "0018,1020\|0010,0010" (0010,0010) PN [ﾔﾏﾀﾞ^ﾀﾛｳ=山田^太郎=やまだ^たろう] # 56, 1 PatientName (0018,1020) LO [123¥456] # 8, 1 SoftwareVersions It has been confirmed by upstream that this is a bug. Patch is under review.
Bug#1054372: python3-django-macaddress: incompatible with python3-django in bookworm
Dear Maintainer,
After enabling tests during build (minimal settings.py is needed) and applying
upstream commit [1][2],
I was able to build your package in a sid chroot environment and all test pass
as well.
Kind Regards
[1]
https://github.com/django-macaddress/django-macaddress/pull/41/commits/a722016312a97
[2] https://github.com/django-macaddress/django-macaddress/pull/44diff -Nru --exclude changelog django-macaddress-1.5.0/debian/control django-macaddress-1.5.0/debian/control
--- django-macaddress-1.5.0/debian/control 2022-04-25 01:57:12.0 +
+++ django-macaddress-1.5.0/debian/control 2023-11-20 08:16:34.0 +
@@ -7,6 +7,10 @@
debhelper-compat (= 12),
dh-python,
python3-all,
+ python3-django,
+ python3-netaddr,
+ python3-pytest,
+ python3-pytest-django,
python3-setuptools,
Standards-Version: 4.5.0
Vcs-Git: https://salsa.debian.org/python-team/packages/django-macaddress.git
diff -Nru --exclude changelog django-macaddress-1.5.0/debian/patches/newdjango.patch django-macaddress-1.5.0/debian/patches/newdjango.patch
--- django-macaddress-1.5.0/debian/patches/newdjango.patch 1970-01-01 00:00:00.0 +
+++ django-macaddress-1.5.0/debian/patches/newdjango.patch 2023-11-20 08:16:20.0 +
@@ -0,0 +1,24 @@
+--- /dev/null
b/macaddress/tests/settings.py
+@@ -0,0 +1,10 @@
++INSTALLED_APPS = [
++'macaddress',
++]
++
++DATABASES = {
++'default': {
++'ENGINE': 'django.db.backends.sqlite3',
++'NAME': 'mydatabase',
++}
++}
+--- a/macaddress/formfields.py
b/macaddress/formfields.py
+@@ -1,6 +1,6 @@
++from django.core.validators import EMPTY_VALUES
+ from django.forms import Field
+-from django.forms.fields import EMPTY_VALUES
+-from django.utils.translation import ugettext_lazy as _
++from django.utils.translation import gettext_lazy as _
+ #"From Django 1.8: The django.forms.util module has been renamed. Use django.forms.utils instead."
+ try:
+ from django.forms.utils import ValidationError
diff -Nru --exclude changelog django-macaddress-1.5.0/debian/patches/series django-macaddress-1.5.0/debian/patches/series
--- django-macaddress-1.5.0/debian/patches/series 1970-01-01 00:00:00.0 +
+++ django-macaddress-1.5.0/debian/patches/series 2023-11-20 08:14:54.0 +
@@ -0,0 +1 @@
+newdjango.patch
diff -Nru --exclude changelog django-macaddress-1.5.0/debian/rules django-macaddress-1.5.0/debian/rules
--- django-macaddress-1.5.0/debian/rules2022-04-25 01:57:12.0 +
+++ django-macaddress-1.5.0/debian/rules2023-11-20 08:13:26.0 +
@@ -5,8 +5,7 @@
#export DH_VERBOSE=1
export PYBUILD_NAME=django-macaddress
-
-override_dh_auto_test:
+export DJANGO_SETTINGS_MODULE=macaddress.tests.settings
%:
dh $@ --with python3 --buildsystem=pybuild
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
Control: retitle -1 dropbear-initramfs makes initramfs non-reproducible Control: severity -1 wishlist Control: tag -1 - patch Hi, On Sun, 19 Nov 2023 at 15:45:22 +0100, Yannik Sembritzki wrote: > One solution would be to simply always use /root-dropbear-initramfs. I'm not in favour of that solution, as ~root doesn't belong to dropbear-initramfs. I think it would be best if the root user and its homedir were created by initramfs-tools itself; failing that it could be created by another directory hook outside src:dropbear (possibly your own custom hook), and dropbear-initramfs's hook could use that. -- Guilhem. signature.asc Description: PGP signature
Bug#1056301: ITP: r-cran-fastdummies -- fast creation of dummy columns and rows from categorical variables
Package: wnpp Severity: wishlist Subject: ITP: r-cran-fastdummies -- fast creation of dummy columns and rows from categorical variables Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-fastdummies Version : 1.7.3 Upstream Author : Jacob Kaplan, * URL : https://cran.r-project.org/package=fastDummies * License : MIT Programming Lang: GNU R Description : fast creation of dummy columns and rows from categorical variables Creates dummy columns from columns that have categorical variables (character or factor types). You can also specify which columns to make dummies out of, or which columns to ignore. Also creates dummy rows from character, factor, and Date columns. This package provides a significant speed increase from creating dummy variables through model.matrix(). Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-fastdummies
Bug#1056274: Acknowledgement (reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory)
I noticed the patch was incomplete. Attached you can find the
correct/complete patch.--- a/debian/hooks/dropbear
+++ b/debian/hooks/dropbear
@@ -24,7 +24,8 @@ for so in $(ldconfig -p | sed -nr 's/^\s*libnss_files\.so\.[0-9]+\s.*=>\s*//p');
copy_exec "$so"
done
-home="$(mktemp --directory -- "$DESTDIR/root-XX")" # avoid collisions with $rootmnt
+home="$DESTDIR/root-dropbear-initramfs"
+mkdir "$home"
chmod 0700 -- "$home"
for x in passwd group; do echo "$x: files"; done >"$DESTDIR/etc/nsswitch.conf"
echo "root:*:0:0::${home#"$DESTDIR"}:/bin/sh" >"$DESTDIR/etc/passwd"
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham,
Am Sun, Nov 19, 2023 at 01:55:04PM -0100 schrieb Graham Inggs:
> On Sat, 18 Nov 2023 at 19:18, Andreas Tille wrote:
> > We need some means to follow ABI changes. In Debian we could use
> > something like r-matrix-abi-VERSION.
>
> Indeed, this is one solution. As you saw in [1], upstream now provide
> an ABI version and a way to extract it:
> > Matrix will commence ABI versioning in 1.6-2. The ABI version will be
> > available
> > in R as Matrix.Version()[["abi"]] and in C as R_MATRIX_ABI_VERSION (from
> > header
> > Matrix/Matrix.h). It is numeric_version("1") in Matrix 1.6-2 and
> > _implicitly_
> > numeric_version("0") in Matrix < 1.6-2.
I'd personally would prefer, if we would implement this ABI versioning
in our packaging in the long term.
> However, since rmatrix has over 100 reverse-dependencies, and only a
> very small number of these are broken by the ABI change, we feel this
> may be overkill, but wouldn't dissuade anyone from proposing patches
> to implement this.
This somehow reminds me to bug #1040038 where r-graphics-engine was
implemented in r-base. I'm willing to help with the implementation of
R_MATRIX_ABI_VERSION but my motivation would be increased if the
authorship of the patches would be mentioned at least in d/changelog
(which was not the case for r-graphics-engine).
> Another option is simply to add a versioned dependency on
> r-cran-matrix to the affected packages, e.g.:
> Depends: r-cran-matrix (>= 1.6-2-1)
> ...but this requires a source change and an upload, is error-prone,
> and a binNMU would not be sufficient.
>
> We liked the change you made to r-cran-tmb [2], as this allows the
> affected packages to be binNMU'd and gain a versioned dependency on
> r-cran-matrix. Would you please apply this to the other affected
> packages (only r-cran-irlba and r-cran-openmx, if I understand
> correctly)?
Done.
> Unfortunately, it seems the two-sided dependency introduced
> subsequently [3], which produces:
> r-cran-matrix (>= 1.6-2-1), r-cran-matrix (<= 1.6-2-199)
> ...is too strict, and r-cran-tmb already needs another rebuild due to
> the upload of rmatrix 1.6-3-1. Would you please revert that change
> and upload?
I've reverted this but in previous discussion[4] with Paul we agreed
upon the strict version dependency. I think this is only necessary for
r-cran-tmb (where upstream is enforcing this with a test I'm hesitating
to patch out). But maybe upstream can work with the freshly implemented
R_MATRIX_ABI_VERSION and thus we can come back to upstream if the
autopkgtest will fire next time (which will happen now after the next
r-cran-matrix update).
Kind regards
Andreas.
> [1] https://stat.ethz.ch/pipermail/r-sig-mac/2023-October/014890.html
> [2]
> https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/92579f72c2db4d51a45cf317f580d790da158f4f
> [3]
> https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/0a4d35d10f9c875863fa0238287cee8ab25aecdd
[4] https://lists.debian.org/debian-r/2023/11/msg7.html
--
http://fam-tille.de
