Bug#1083059: hfsplus: FTBFS with gcc-14
Package: hfsplus
Version: 1.0.4-17.1ubuntu1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: daniel.bung...@canonical.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/2083086
hfsplus is FTBFS with gcc-14 on presumably all BIG_ENDIAN arches.
https://launchpadlibrarian.net/749243763/buildlog_ubuntu-oracular-s390x.hfsplus_1.0.4-17.1build1_BUILDING.txt.gz
I have only observed this on s390x on Ubuntu and assume it would also apply to
Debian.
In file included from partitions.c:29:
partitions.c: In function ‘partition_fillstruct’:
swab.h:51:51: error: assignment to ‘char *’ from incompatible pointer type
‘UInt16 *’ {aka ‘short unsigned int *’} [-Wincompatible-pointer-types]
51 | #define bswabU16_inc(ptr) *((UInt16*) (ptr)); ptr = (UInt16*)ptr + 1
| ^
partitions.c:59:23: note: in expansion of macro ‘bswabU16_inc’
59 | p->pmSig = bswabU16_inc( buf);
| ^~~~
this continues for all the bswabUXX_inc in partition_fillstruct.
I addressed this for Ubuntu (mostly) as follows:
--- a/libhfsp/src/swab.h
+++ b/libhfsp/src/swab.h
@@ -48,25 +48,25 @@
#define bswabU16(val) val
-#define bswabU16_inc(ptr) *((UInt16*) (ptr)); ptr = (UInt16*)ptr + 1
+#define bswabU16_inc(ptr) *((UInt16*) (ptr)); ptr = (void *)((UInt16*)ptr + 1)
/* Only available as a GCC extension, but required on sparc due to
alignment issues in some of the on-disk structs */
#if defined(__GNUC__) && defined(__sparc__)
#define bswabU32_inc(ptr) ({ \
unsigned char *c = (char*)ptr; \
- ptr = ((UInt32 *)ptr) + 1; \
+ ptr = (void *)(((UInt32 *)ptr) + 1);\
((c[0] << 24)+(c[1] << 16)+(c[2] << 8)+c[3]);})
#define bswabU64_inc(ptr) ({ \
unsigned char *c = (char*)ptr; \
UInt64 val = 0; \
int i = 0; \
- ptr = ((UInt64 *)ptr) + 1; \
+ ptr = (void *)(((UInt64 *)ptr) + 1);\
while (i < 8) \
val += (c[i] << (8*(7-i++))); \
val;})
#else
-#define bswabU32_inc(ptr) *((UInt32*) (ptr)); ptr = (UInt32*)ptr + 1
-#define bswabU64_inc(ptr) *((UInt64*) (ptr)); ptr = (UInt64*)ptr + 1
+#define bswabU32_inc(ptr) *((UInt32*) (ptr)); ptr = (void *)((UInt32*)ptr + 1)
+#define bswabU64_inc(ptr) *((UInt64*) (ptr)); ptr = (void *)((UInt64*)ptr + 1)
#endif
#define bstoreU16_inc(ptr, val) *((UInt16*) (ptr)) = val; ptr =
(void*)((UInt16*)ptr + 1)
The Ubuntu version I uploaded is different because of a flaw on the
defined(__sparc__) path that Ubuntu won't use, I expect the above is corret.
-Dan
Bug#1075721: octave-dicom: use-after-free with dicomdict
Source: octave-dicom
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
I wanted to forward along a fix I have done for Ubuntu for octave-dicom.
Ubuntu builds of octave-dicom were FTBFS on the built-in testsuite with
use-after-free / segfault type issues. I have not reproduced this build
failure on Sid, but memory corruption issues are treacherous and might show up
later.
If desired, more details can be found at
https://bugs.launchpad.net/ubuntu/+source/octave-dicom/+bug/2069660 ,
but the summary is that I have moved the std::maps used by dicomdict to static
storage to address this. I believe that the destructors are getting confused
with the multiple copies of dicomdict, due to the functionality being built
into several plugins and plugins being loaded by octave with RTLD_GLOBAL.
The patch passes the built-in testsuite, along with my attempts to confuse the
dict information loaded with specific plugin ordering.
Please see attached. Also, the upstream bug tracker at
https://octave.space/savannah/?Action=get&Format=HTMLCSS&Title=[octave%20forge]%20(dicom)
seems to be down, so if you have information about how best to reach upstream,
I'd appreciate it.
-Dan
P.S. - this is my second attempt at forwarding this, so if you see a duplicate
assume mailserver weirdness and just close it.
Description: fix use-after-free due to symbol collisions across plugins
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2069660
Forwarded: no
Last-Update: 2024-06-28
Move these symbols to static, which helps shield them from strange cleanup
ordering of the maps that can result in use-after-free due to the map
destructors performing an overwriting clear and that the symbols are referenced
from multiple plugins.
--- a/src/dicomdict.cpp
+++ b/src/dicomdict.cpp
@@ -51,9 +51,9 @@
const char * factory_dicom_dict_filename="octavedicom.dic";
static std::string dic_filename(factory_dicom_dict_filename);
-std::map tagmap ;
-std::map keymap ;
-std::map dict ;
+static std::map tagmap ;
+static std::map keymap ;
+static std::map dict ;
void insert(const char *k, const gdcm::Tag t, const gdcm::DictEntry e)
{
Bug#1067690: (no subject)
Source: pygame-sdl2 Version: 8.1.3-1 Severity: normal Tags: ftbfs X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, pygame-sdl2 will FTBFS with the current incarnation of cython3. Switching to cython3-legacy produces a passing build. Confirmed building with this change on sid and Ubuntu noble. --- a/debian/control +++ b/debian/control @@ -6,7 +6,7 @@ Uploaders: Markus Koschany Build-Depends: - cython3, + cython3-legacy, debhelper-compat (= 13), dh-sequence-python3, libsdl2-dev, -Dan
Bug#1065725: adns: FTBFS on arm{el,hf}: FAILED ./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0
Greetings!
I took a look at this bug today.
I found that the regress testsuite make use of some negative offsets, which
seem to perplex the reader on 32 bit systems.
Please see the attached patch, which has allowed this to build for Ubuntu.
-Dan
Author: Dan Bungert
Description: Fix reads of signed values into unsigned variables
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2057735
Bug-Debian: https://bugs.debian.org/1065725
Forwarded: yes
Last-Update: 2024-03-14
The regress testsuite makes use of time offsets to mock the passage of time,
and some of the usec values are expressed as negative numbers. Update the
reader to be able to handle that.
--- a/regress/hplayback.c.m4
+++ b/regress/hplayback.c.m4
@@ -108,7 +108,8 @@
void Tensuresetup(void) {
int fd;
int chars;
- unsigned long sec, usec;
+ time_t sec;
+ suseconds_t usec;
Tensure_reportfile();
Tensure_fuzzrawfile();
@@ -124,7 +125,7 @@
if (!adns__vbuf_ensure(&vb2,1000)) Tnomem();
fgets(vb2.buf,vb2.avail,Tinputfile); Pcheckinput();
chars= -1;
- sscanf(vb2.buf," start %lu.%lu%n",&sec,&usec,&chars);
+ sscanf(vb2.buf," start %lld.%ld%n",&sec,&usec,&chars);
if (chars==-1) Psyntax("start time invalid");
currenttime.tv_sec= sec;
currenttime.tv_usec= usec;
@@ -170,12 +171,13 @@
static void P_updatetime(void) {
int chars;
- unsigned long sec, usec;
+ time_t sec;
+ suseconds_t usec;
if (!adns__vbuf_ensure(&vb2,1000)) Tnomem();
fgets(vb2.buf,vb2.avail,Tinputfile); Pcheckinput();
chars= -1;
- sscanf(vb2.buf," +%lu.%lu%n",&sec,&usec,&chars);
+ sscanf(vb2.buf," +%lld.%ld%n",&sec,&usec,&chars);
if (chars==-1) Psyntax("update time invalid");
currenttime.tv_sec+= sec;
currenttime.tv_usec+= usec;
Bug#1064926: python-requests-unixsocket: test flake on HEAD request that can lead to FTBFS
Source: python-requests-unixsocket
Version: 0.3.0-3
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
While doing an upload to Ubuntu for another python-requests-unixsocket
fix (Debian bug 1063892), we observed that the package may FTBFS on the
testsuite. The HEAD request portion of some of the tests may fail,
apparently due to particular write/read patterns that can leave excess
data around for the next test request - the unread body.
In local testing the failure rate was small (< 5%), but on official
buidlers it was apparently 100%, so system load is likely a factor.
To that end an upstream PR has been opened:
https://github.com/msabramo/requests-unixsocket/pull/71
--- a/requests_unixsocket/testutils.py
+++ b/requests_unixsocket/testutils.py
@@ -51,6 +51,8 @@
('X-Requested-Query-String', environ['QUERY_STRING']),
('X-Requested-Path', environ['PATH_INFO'])]
body_bytes = b'Hello world!'
+if environ["REQUEST_METHOD"] == "HEAD":
+body_bytes = b''
start_response(status_text, response_headers)
logger.debug(
'WSGIApp.__call__: Responding with '
Also filed in Ubuntu as https://pad.lv/2053154
-Dan
Bug#1063817: debconf-copydb pipe writes to GLOB file instead of stdout
Package: debconf Version: 1.5.85 Severity: normal X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, While debugging a FTBFS in Ubiquity, I observed that the usage of debconf-copydb regressed when using version 1.5.85 of debconf. The previous-in-Ubuntu version 1.5.82 of debconf was OK. That invocation looks roughly like: debconf-copydb templatedb pipe --config=Name:pipe --config=Driver:Pipe --config=InFd:none ... Bisecting debconf from there found commit 5db857ade00953496bfdb7edb884296bebc41885: "Avoid two-argument open" Further tracing found the following change to Debconf/DbDriver/Pipe.pm around line 120: - open ($fh, '>-'); + open ($fh, '>', \*STDOUT); An additional symptom of this problem is GLOB files are created in CWD with names that look like: GLOB(0x0123456789ab) Pointing the above to above to configdb on a fairly stock Debian Sid installation produces an equivalent result - GLOB file creation instead of the output. Is the 3-argument form this? open ($fh, '>&', \*STDOUT); Originally filed as LP: #2052982. -Dan
Bug#1061468: gloo: attempts to build on unsupported 32 bit systems
[Paul Wise] > The right way to do this is to Build-Depend: architecture-is-64-bit Thanks Paul, I didn't know about that. Clearly architecture-is-64-bit is the better solution. [Petter Reinholdtsen] > [Dan Bungert] > > I suggest adjusting the control file to reflect this state so that > > builds are only attempted on 64 bit systems. > Why? Which problem are you trying to solve? Doing such change will > fail to automatically discover if gloo start working on other > architectures, and require extra work to keep the list of architectures > up to date as Debian evolves. As far as I can see, the disadvantage of > trying to build on non-supported architectures is a few wasted CPU > cycles, while the advantage is less human time spent on package > maintenance. Did I miss something? To me, saving humans time is more > valuable than saving CPU time. Saving humans time is a tradeoff I will agree with. Another angle though is the time of people looking at problems across an architecture or, like me, who are temporarily looking at this package and checking why some of the builds fail. These "some builds fail" bugs can sometimes indicate a flaky build and that the rest of the builds can't be considered stable. Of course that's not the case here - it's a straightforward case of builds being disabled for 32 bit arches, which is a reasonable decision for upstream to make. No problem there. A bit unfortunate that cmake has this critical string not at the end of the log file, so the "tail of log" reports at https://buildd.debian.org/status/package.php?p=gloo are missing this detail, but that's a cmake issue. So the tradeoff I'm proposing is making it simpler for others looking at the package, to remove failed builds that we know will fail. It indeed has the downside that if the 32 bit support status changes it will require a change to reverse. Do you consider that scenario likely? There is side benefit here that the CPU time being saved is a bit more rarefied than amd64. If the above is uncompelling, you are of course free to decline the change. -Dan
Bug#1062527: libimage-info-perl: ADT failure if libxml-simple-perl chosen instead of libxml-libxml-perl
Package: libimage-info-perl Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, I believe the following dependency is not quite correct. Today it says: Depends: ... libxml-libxml-perl | libxml-simple-perl If autopkgtest is run and libxml-libxml-perl is not installed, you get: 414s # Can't locate XML/LibXML/Reader.pm in @INC (you may need to install the XML::LibXML::Reader module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/share/perl5/Image/Info/SVG/XMLLibXMLReader.pm line 21. To address this, the dependency list should change to say libxml AND simple. The justification for that is based on code inspection of l/I/I/S/XMLLibXMLReader.pm, which says: use XML::LibXML::Reader; ... require XML::Simple; I'm not an expert on this package, or perl in general, so if you think the handling of libxml-simpler-perl is not quite correct, please implement otherwise. But the depend on libxml-libxml-perl seems quite firm. For Ubuntu I have uploaded the `and` version of this dependency in place of the `or`. This bug report was also filed in Ubuntu and can be found at https://launchpad.net/bugs/2051970 -Dan
Bug#1060173: ruby-hiredis FTBFS with hiredis 1.2.0-6
I examined this bug a bit. In test/reader_test.rb, test_nil / test_null_multi_bulk are both failing. If these tests are commented out, the package build will complete. Doesn't sound like a great idea though as it's not clear to me why these tests regressed. -Dan
Bug#1061468: gloo: attempts to build on unsupported 32 bit systems
Source: gloo
Version: 0.0~git20230519.597accf-2
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
gloo attempts to build on 32 bit systems.
https://buildd.debian.org/status/package.php?p=gloo
We know this will not work, as cmake reports the following:
> Gloo can only be built on 64-bit systems.
I suggest adjusting the control file to reflect this state so that
builds are only attempted on 64 bit systems. Something like this should
work.
@@ -17,7 +17,7 @@ Rules-Requires-Root: no
Package: libgloo-dev
Section: libdevel
-Architecture: any
+Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64
loong64 ppc64 sparc64
Depends: libgloo0 (= ${binary:Version}),
libhiredis-dev,
libibverbs-dev,
-Dan
Bug#1058648: p11-kit: FTBFS if bash-completion is installed
Source: p11-kit Version: 0.25.3-2 Severity: normal X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, If bash-completion happens to be installed at the time of build, the build will fail. This can be observed when building on Debian Sid or Ubuntu Noble. dh_missing dh_missing: warning: usr/share/bash-completion/completions/p11-kit exists in debian/tmp but is not installed to anywhere (related file: "debian/tmp/usr/bin/p11-kit") dh_missing: warning: usr/share/bash-completion/completions/trust exists in debian/tmp but is not installed to anywhere (related file: "debian/tmp/usr/bin/trust") dh_missing: error: missing files, aborting full sample log: https://launchpadlibrarian.net/702524075/buildlog_ubuntu-noble-amd64.p11-kit_0.25.3-2ubuntu1_BUILDING.txt.gz Presumably the files should be added to the p11-kit binary package, or adding "usr/share/bash-completion/*" to d/not-installed will address the FTBFS. Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/2046389 -Dan
Bug#1040633: pilkit autopkg tests fail with pillow 10.0.0
Upstream proposal resolves this: https://github.com/matthewwithanm/pilkit/pull/66/commits/e2eb73e1798865a201e570fced0bac195b2a590c -Dan
Bug#1040853: python-lockfile autopkg test fail with setuptools 68
Just wanted to quickly confirm that the same fix proposed at: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1040854;filename=python-tinyrpc_0.6-4ubuntu1.debdiff;msg=10 works well for python-lockfile. -Dan
Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"
On Sun, Jul 16, 2023 at 12:05:34PM +0200, Gregor Riepl wrote: > Do we need to backport it against 4.13 in some way, or was this just a > goof-up when you reported the bug? I'm sorry Gregor, this is what happened, I mis-reported against 4.13. I hope it wasn't too much of a time waste. Fixing 5.0.0 should be sufficient. Thank you. -Dan
Bug#1040893: ocaml-qcheck: autopkgtest failures with ocaml-dune 3.9
Source: ocaml-qcheck
Version: 0.20-1
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
On Sid and Ubuntu Mantic, autopkgtest failures can be observed.
The first failure has to do with dropping the dune -> ocaml-dune transitional
package:
Package dune is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
ocaml-dune
E: Package 'dune' has no installation candidate
Updating the package name in the test dependencies is sufficient.
If that is resolved, the following failure is seen:
autopkgtest [20:11:29]: test test: [---
Error: No dune-project file has been found. A default one is assumed but the
project might break when dune is upgraded. Please create a dune-project file.
Hint: generate the project file with: $ dune init project
autopkgtest [20:11:30]: test test: ---]
To address the second problem, I propose adding a dune-project file for
autopkgtest use.
Please see the attached debdiff which addresses both of the above issues.
Thanks.
-Dan
diff -Nru ocaml-qcheck-0.20/debian/changelog ocaml-qcheck-0.20/debian/changelog
--- ocaml-qcheck-0.20/debian/changelog 2023-02-03 22:46:04.0 -0700
+++ ocaml-qcheck-0.20/debian/changelog 2023-07-11 17:35:58.0 -0600
@@ -1,3 +1,10 @@
+ocaml-qcheck (0.20-2) unstable; urgency=medium
+
+ * fix autopkgtest - update ocaml-dune test dependency, supply a dune project
+file for examples
+
+ -- Dan Bungert Tue, 11 Jul 2023 17:35:58 -0600
+
ocaml-qcheck (0.20-1) unstable; urgency=medium
[ Stéphane Glondu ]
diff -Nru ocaml-qcheck-0.20/debian/tests/control
ocaml-qcheck-0.20/debian/tests/control
--- ocaml-qcheck-0.20/debian/tests/control 2023-02-03 22:46:04.0
-0700
+++ ocaml-qcheck-0.20/debian/tests/control 2023-07-11 17:35:58.0
-0600
@@ -1,3 +1,3 @@
Tests: test
-Depends: ocaml-nox, ocaml-findlib, dune, @
+Depends: ocaml-nox, ocaml-findlib, ocaml-dune, @
Restrictions: allow-stderr
diff -Nru ocaml-qcheck-0.20/debian/tests/dune-project-examples
ocaml-qcheck-0.20/debian/tests/dune-project-examples
--- ocaml-qcheck-0.20/debian/tests/dune-project-examples1969-12-31
17:00:00.0 -0700
+++ ocaml-qcheck-0.20/debian/tests/dune-project-examples2023-07-11
17:35:58.0 -0600
@@ -0,0 +1,2 @@
+(lang dune 2.2)
+(name qcheck-examples)
diff -Nru ocaml-qcheck-0.20/debian/tests/test
ocaml-qcheck-0.20/debian/tests/test
--- ocaml-qcheck-0.20/debian/tests/test 2023-02-03 22:46:04.0 -0700
+++ ocaml-qcheck-0.20/debian/tests/test 2023-07-11 17:35:58.0 -0600
@@ -6,6 +6,7 @@
trap "rm -rf ${testdir}" 0 INT QUIT ABRT PIPE TERM
cp -r "$(dirname "$0")/../../example" "${testdir}/example"
+cp debian/tests/dune-project-examples "${testdir}/example/dune-project"
cd "${testdir}/example"
Bug#1040874: ocaml-dune: Please add ocaml:Provides to d/control
Source: ocaml-dune
Version: 3.9.0-2
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
utop shows the following in testing migration:
* libutop-ocaml-dev/amd64 has unsatisfiable dependency
Attempting an install of libutop-ocaml-dev reports:
libutop-ocaml-dev : Depends: libdune-ocaml-dev-v9190 but it is not installable
I believe that adding the ocaml:Provides will resolve this. Debdiff attached.
-Dan
diff -Nru ocaml-dune-3.9.0/debian/changelog ocaml-dune-3.9.0/debian/changelog
--- ocaml-dune-3.9.0/debian/changelog 2023-07-05 02:40:57.0 -0600
+++ ocaml-dune-3.9.0/debian/changelog 2023-07-11 13:41:34.0 -0600
@@ -1,3 +1,10 @@
+ocaml-dune (3.9.0-3) unstable; urgency=medium
+
+ * Rebuild against new OCAML ABIs.
+ * Add dh_ocaml compatible substitution variables per OCaml packaging policy
+
+ -- Dan Bungert Tue, 11 Jul 2023 13:41:34 -0600
+
ocaml-dune (3.9.0-2) unstable; urgency=medium
* Team upload.
diff -Nru ocaml-dune-3.9.0/debian/control ocaml-dune-3.9.0/debian/control
--- ocaml-dune-3.9.0/debian/control 2023-07-05 02:40:57.0 -0600
+++ ocaml-dune-3.9.0/debian/control 2023-07-11 13:41:34.0 -0600
@@ -22,7 +22,9 @@
whitedune (<< 0.30.10-2.2),
dune (<< 1.6.2-3)
Replaces: jbuilder (<< 1.0~beta20-1), whitedune (<< 0.30.10-2.2), dune (<<
1.6.2-3)
-Provides: jbuilder
+Provides:
+ jbuilder,
+ ${ocaml:Provides}
Depends:
${ocaml:Depends},
${shlibs:Depends},
@@ -41,6 +43,8 @@
${ocaml:Depends},
${shlibs:Depends},
${misc:Depends}
+Provides:
+ ${ocaml:Provides}
Suggests:
ocaml-findlib
Description: composable build system for OCaml projects (libraries)
Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"
Source: cura-engine
Version: 1:4.13.0-1build1
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
Visible in both Sid and Ubuntu Mantic is the following autopkgtest error:
[ERROR] Trying to retrieve setting with no value given: 'adhesion_extruder_nr'
See the attached patch, which is just a trivial backport of
https://github.com/Ultimaker/CuraEngine/pull/1693
(I submitted this bug twice before, if duplicates show up later for some
reason please forgive me)
-Dan
Description: Fix ADT - setting with no value given: 'adhesion_extruder_nr'
Origin:
https://github.com/Ultimaker/CuraEngine/pull/1693/commits/adecda53fff5c77ccf43a54ee37d5654a4032858
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2026769
Bug: https://github.com/Ultimaker/CuraEngine/pull/1693
Forwarded: not-needed
Last-Update: 2023-07-10
--- a/src/raft.cpp
+++ b/src/raft.cpp
@@ -18,7 +18,7 @@
void Raft::generate(SliceDataStorage& storage)
{
assert(storage.raftOutline.size() == 0 && "Raft polygon isn't generated
yet, so should be empty!");
-const Settings& settings =
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("adhesion_extruder_nr").settings;
+const Settings& settings =
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("raft_base_extruder_nr").settings;
const coord_t distance = settings.get("raft_margin");
constexpr bool include_support = true;
constexpr bool include_prime_tower = true;
@@ -51,16 +51,19 @@
coord_t Raft::getTotalThickness()
{
-const ExtruderTrain& train =
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("adhesion_extruder_nr");
-return train.settings.get("raft_base_thickness")
-+ train.settings.get("raft_interface_layers") *
train.settings.get("raft_interface_thickness")
-+ train.settings.get("raft_surface_layers") *
train.settings.get("raft_surface_thickness");
+const Settings& mesh_group_settings
=Application::getInstance().current_slice->scene.current_mesh_group->settings;
+const ExtruderTrain& base_train =
mesh_group_settings.get("raft_base_extruder_nr");
+const ExtruderTrain& interface_train =
mesh_group_settings.get("raft_interface_extruder_nr");
+const ExtruderTrain& surface_train =
mesh_group_settings.get("raft_surface_extruder_nr");
+return base_train.settings.get("raft_base_thickness")
++ interface_train.settings.get("raft_interface_layers") *
interface_train.settings.get("raft_interface_thickness")
++ surface_train.settings.get("raft_surface_layers") *
surface_train.settings.get("raft_surface_thickness");
}
coord_t Raft::getZdiffBetweenRaftAndLayer1()
{
const Settings& mesh_group_settings =
Application::getInstance().current_slice->scene.current_mesh_group->settings;
-const ExtruderTrain& train =
mesh_group_settings.get("adhesion_extruder_nr");
+const ExtruderTrain& train =
mesh_group_settings.get("raft_surface_extruder_nr");
if (mesh_group_settings.get("adhesion_type") !=
EPlatformAdhesion::RAFT)
{
return 0;
@@ -94,12 +97,15 @@
size_t Raft::getTotalExtraLayers()
{
-const ExtruderTrain& train =
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("adhesion_extruder_nr");
-if (train.settings.get("adhesion_type") !=
EPlatformAdhesion::RAFT)
+const Settings& mesh_group_settings
=Application::getInstance().current_slice->scene.current_mesh_group->settings;
+const ExtruderTrain& base_train =
mesh_group_settings.get("raft_base_extruder_nr");
+const ExtruderTrain& interface_train =
mesh_group_settings.get("raft_interface_extruder_nr");
+const ExtruderTrain& surface_train =
mesh_group_settings.get("raft_surface_extruder_nr");
+if (base_train.settings.get("adhesion_type") !=
EPlatformAdhesion::RAFT)
{
return 0;
}
-return 1 + train.settings.get("raft_interface_layers") +
train.settings.get("raft_surface_layers") + getFillerLayerCount();
+return 1 + interface_train.settings.get("raft_interface_layers") +
surface_train.settings.get("raft_surface_layers") +
getFillerLayerCount();
}
--- a/src/sliceDataStorage.cpp
+++ b/src/sliceDataStorage.cpp
@@ -595,12 +595,15 @@
}
coord_t adhesion_size = 0; //Make sure there is enough room for the
platform adhesion around support.
-const ExtruderTrain& adhesion_extruder =
mesh_group_settings.get("adhesion_extruder_nr");
+const ExtruderTrain& base_train =
mesh_group_settings.get("raft_base_extruder_nr");
+const ExtruderTrain& interface_train =
mesh_group_settings.get("raft_interface_extruder_nr");
+const ExtruderTrain& surface_train =
mesh_group_settings.get("raft_surface_extruder_nr");
+const ExtruderTrain& skirt_brim_train =
mesh_group_settings.get("skirt_brim_extruder_nr");
coord_t extra_skirt_line_width = 0;
const std::vector is_extruder_used = getExtrudersUsed();
Bug#1024205: cloudpickle: FTBFS with py3.11
https://github.com/cloudpipe/cloudpickle/pull/486/commits/9b332800fa09bec1f03fd4dd10ca69d1655c809c is also desired, for compatibility with python3.11 3.11.0-3. -Dan
Bug#1024335: diffoscope: FTBFS against python 3.11
Package: diffoscope
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1996926
diffoscope will FTBFS in tests when run with python 3.11. Can be observed both
on Debian Sid and Ubuntu Lunar.
https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/d/diffoscope/20221103_074104_c1d72@/log.gz
(that log also shows a lxml error, but that problem goes away when triggering
tests with lxml from proposed)
__ test_diff __
differences = []
@skip_unless_file_version_is_at_least("5.39")
@skipif(
sys.version_info < (3, 8),
reason="Python 3.7 cannot de-marshal test1.pyc-renamed",
)
def test_diff(differences):
assert_diff_startswith(
> differences[0],
"pyc_expected_diff",
)
E IndexError: list index out of range
differences = []
tests/comparators/test_python.py:61: IndexError
Bug#1024287: django-assets: FTBFS against python 3.11
Package: django-assets Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar Dear Maintainer, This bug report was also filed in Ubuntu and can be found at https://launchpad.net/bugs/1996828 django-assets will FTBFS in tests with python 3.11: https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/d/django-assets/20221102_154051_2159f@/log.gz A fix for this has been proposed upstream: https://github.com/miracle2k/django-assets/pull/104 -Dan
Bug#1024205: cloudpickle: FTBFS with py3.11
Package: cloudpickle
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1996655
The description, from Dan Bungert, follows:
Cloudpickle will FTBFS with an impressive array of unittest failures when
attempting to use python 3.11.
See attached for what I'm uploading for Ubuntu, which is backports of 2 commits
from upstream.
-Dan
diff -Nru cloudpickle-2.0.0/debian/patches/0cb1910.patch
cloudpickle-2.0.0/debian/patches/0cb1910.patch
--- cloudpickle-2.0.0/debian/patches/0cb1910.patch 1969-12-31
17:00:00.0 -0700
+++ cloudpickle-2.0.0/debian/patches/0cb1910.patch 2022-11-15
16:40:33.0 -0700
@@ -0,0 +1,122 @@
+Description: Improve compatibility with "nogil" Python and 3.11
+Author: Dan Bungert
+Origin:
https://github.com/cloudpipe/cloudpickle/pull/470/commits/0cb191032d4b7913e6a66e3f24788668efbd10dd
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1996655
+Bug: https://github.com/cloudpipe/cloudpickle/pull/470
+Last-Update: 2022-11-15
+
+Patch modified from original commit by `quilt refresh`.
+--- a/cloudpickle/cloudpickle.py
b/cloudpickle/cloudpickle.py
+@@ -327,11 +327,10 @@
+ """
+ out_names = _extract_code_globals_cache.get(co)
+ if out_names is None:
+-names = co.co_names
+ # We use a dict with None values instead of a set to get a
+ # deterministic order (assuming Python 3.6+) and avoid introducing
+ # non-deterministic pickle bytes as a results.
+-out_names = {names[oparg]: None for _, oparg in _walk_global_ops(co)}
++out_names = {name: None for name in _walk_global_ops(co)}
+
+ # Declaring a function inside another one using the "def ..."
+ # syntax generates a constant code object corresponding to the one
+@@ -517,13 +516,12 @@
+
+ def _walk_global_ops(code):
+ """
+-Yield (opcode, argument number) tuples for all
+-global-referencing instructions in *code*.
++Yield referenced name for all global-referencing instructions in *code*.
+ """
+ for instr in dis.get_instructions(code):
+ op = instr.opcode
+ if op in GLOBAL_OPS:
+-yield op, instr.arg
++yield instr.argval
+
+
+ def _extract_class_dict(cls):
+@@ -793,6 +791,11 @@
+ return func
+
+
++def _make_function(code, globals, name, argdefs, closure):
++globals["__builtins__"] = __builtins__
++return types.FunctionType(code, globals, name, argdefs, closure)
++
++
+ def _make_empty_cell():
+ if False:
+ # trick the compiler into creating an empty cell in our lambda
+--- a/cloudpickle/cloudpickle_fast.py
b/cloudpickle/cloudpickle_fast.py
+@@ -35,7 +35,7 @@
+ _is_parametrized_type_hint, PYPY, cell_set,
+ parametrized_type_hint_getinitargs, _create_parametrized_type_hint,
+ builtin_code_type,
+-_make_dict_keys, _make_dict_values, _make_dict_items,
++_make_dict_keys, _make_dict_values, _make_dict_items, _make_function,
+ )
+
+
+@@ -248,7 +248,7 @@
+ # of the specific type from types, for example:
+ # >>> from types import CodeType
+ # >>> help(CodeType)
+-if hasattr(obj, "co_columntable"): # pragma: no branch
++if hasattr(obj, "co_exceptiontable"): # pragma: no branch
+ # Python 3.11 and later: there are some new attributes
+ # related to the enhanced exceptions.
+ args = (
+@@ -256,9 +256,8 @@
+ obj.co_kwonlyargcount, obj.co_nlocals, obj.co_stacksize,
+ obj.co_flags, obj.co_code, obj.co_consts, obj.co_names,
+ obj.co_varnames, obj.co_filename, obj.co_name, obj.co_qualname,
+-obj.co_firstlineno, obj.co_linetable, obj.co_endlinetable,
+-obj.co_columntable, obj.co_exceptiontable, obj.co_freevars,
+-obj.co_cellvars,
++obj.co_firstlineno, obj.co_linetable, obj.co_exceptiontable,
++obj.co_freevars, obj.co_cellvars,
+ )
+ elif hasattr(obj, "co_linetable"): # pragma: no branch
+ # Python 3.10 and later: obj.co_lnotab is deprecated and constructor
+@@ -271,6 +270,18 @@
+ obj.co_firstlineno, obj.co_linetable, obj.co_freevars,
+ obj.co_cellvars
+ )
++elif hasattr(obj, "co_nmeta"): # pragma: no branch
++# "nogil" Python: modified attributes from 3.9
++args = (
++obj.co_argcount, obj.co_posonlyargcount,
++obj.co_kwonlyargcount, obj.co_nlocals, obj.co_framesize,
++obj.co_ndefaultargs, obj.co_nmeta,
++obj.co_flags, obj.co_code, obj.co_consts,
++obj.co_varnames, obj.co_filename, obj.co_name,
++obj.co_firstlineno, obj.co_lnotab, obj.co_exc_handlers,
Bug#1020883: klibc: Autopkgtest failure with .note.GNU-stack stderr messages
Source: klibc
Version: 2.0.10-4
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
When running autopkgtest for klibc on Sid or Ubuntu Kinetic, the test will fail
due to messages on stderr. They look like:
https://ci.debian.net/data/autopkgtest/unstable/amd64/k/klibc/26310446/log.gz
/usr/bin/x86_64-linux-gnu-ld: warning: mmap.o: missing .note.GNU-stack section
implies executable stack
/usr/bin/x86_64-linux-gnu-ld: NOTE: This behaviour is deprecated and will be
removed in a future version of the linker
Additionally, and not really related, 32 bit arches have a different problem.
I can reproduce this on Sid in private testing.
https://launchpadlibrarian.net/625440146/buildlog_ubuntu-kinetic-i386.klibc_2.0.10-4_BUILDING.txt.gz
/<>/usr/klibc/__static_init.c
In file included from /<>/usr/klibc/../include/stdlib.h:13,
from /<>/usr/klibc/libc_init.c:23,
from /<>/usr/klibc/__static_init.c:2:
/<>/usr/klibc/../include/fcntl.h:36:9: error: expected
specifier-qualifier-list before ‘__ARCH_FLOCK64_PAD’
36 | __ARCH_FLOCK64_PAD
Applying these commits addresses these items.
* 2acbe15d7a8093cfa295aadc56707892e87a7eaf
* bb2fde5ddbc18a2e7795ca4d24759230c2aae9d0
Attached is what I'm going to upload to Ubuntu.
Hope that helps.
-Dan
diff -Nru klibc-2.0.10/debian/changelog klibc-2.0.10/debian/changelog
--- klibc-2.0.10/debian/changelog 2022-01-30 16:28:16.0 -0700
+++ klibc-2.0.10/debian/changelog 2022-09-27 14:58:43.0 -0600
@@ -1,3 +1,12 @@
+klibc (2.0.10-4ubuntu1) kinetic; urgency=medium
+
+ * Cherry-pick 2acbe15 to fix a typo for KLIBCSTACKFLAGS, needed so that the
+correct LDFLAGS are in use.
+ * Cherry-pick bb2fde5 to fix an issue with usage of __ARCH_FLOCK64_PAD on 32
+bit systems.
+
+ -- Dan Bungert Tue, 27 Sep 2022 14:58:43 -0600
+
klibc (2.0.10-4) unstable; urgency=medium
* d/control, d/rules: Remove ccache from $PATH instead of Build-Conflicting
diff -Nru klibc-2.0.10/debian/patches/fix-32bit-vs-FLOCK64.patch
klibc-2.0.10/debian/patches/fix-32bit-vs-FLOCK64.patch
--- klibc-2.0.10/debian/patches/fix-32bit-vs-FLOCK64.patch 1969-12-31
17:00:00.0 -0700
+++ klibc-2.0.10/debian/patches/fix-32bit-vs-FLOCK64.patch 2022-09-27
14:58:43.0 -0600
@@ -0,0 +1,26 @@
+Origin:
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=bb2fde5ddbc18a2e7795ca4d24759230c2aae9d0
+Last-Update: 2022-09-27
+Bug-Debian:
+Forwarded: not-needed
+Subject: [klibc] fcntl: Fix build failure for some architectures with Linux
5.19
+
+Starting from Linux 5.19, the kernel UAPI headers now only define
+__ARCH_FLOCK64_PAD if the architecture actually needs padding in
+struct flock64. Wrap its use with #ifdef,
+
+Signed-off-by: Ben Hutchings
+
+diff --git a/usr/include/fcntl.h b/usr/include/fcntl.h
+index ed703a62..cb2e4e53 100644
+--- a/usr/include/fcntl.h
b/usr/include/fcntl.h
+@@ -33,7 +33,9 @@ struct flock {
+ __kernel_loff_t l_start;
+ __kernel_loff_t l_len;
+ __kernel_pid_t l_pid;
++#ifdef __ARCH_FLOCK64_PAD
+ __ARCH_FLOCK64_PAD
++#endif
+ };
+
+ #ifdef F_GETLK64
diff -Nru klibc-2.0.10/debian/patches/fix-KLIBCSTACKFLAGS.patch
klibc-2.0.10/debian/patches/fix-KLIBCSTACKFLAGS.patch
--- klibc-2.0.10/debian/patches/fix-KLIBCSTACKFLAGS.patch 1969-12-31
17:00:00.0 -0700
+++ klibc-2.0.10/debian/patches/fix-KLIBCSTACKFLAGS.patch 2022-09-27
14:58:43.0 -0600
@@ -0,0 +1,44 @@
+Origin:
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=2acbe15d7a8093cfa295aadc56707892e87a7eaf
+Last-Update: 2022-09-27
+Bug-Debian:
+Forwarded: not-needed
+Subject: [klibc] Kbuild: Properly disable executable stacks in static builds
+
+I typo'd the variable name KLIBCSTACKFLAGS in the value of
+KLIBCCFLAGS, leaving the stack executable in statically linked
+executables. Fix that.
+
+Executables using a shared library did not have this problem, unless
+they included assembly language sources. C compilers generate the
+no-executable-stack header by default, and the interpreter definition
+that's statically linked into such executables was built with a
+correctly spelt KLIBCSTACKFLAGS as an extra option.
+
+Fixes: c562319cdba0 ("[klibc] Kbuild: Add a per-architecture option to
...")
+Signed-off-by: Ben Hutchings
+
+diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc
+index e88bc003..64da31ac 100644
+--- a/scripts/Kbuild.klibc
b/scripts/Kbuild.klibc
+@@ -133,7 +133,7 @@ KLIBCDEFS+= -D__KLIBC__=$(KLIBCMAJOR) \
+ -D_BITSIZE=$(KLIBCBITSIZE)
+ KLIBCCPPFLAGS+= $(KLIBCDEFS)
+ KLIBCCFLAGS += $(KLIBCCPPFLAGS) $(KLIBCREQFLAGS) $(KLIBCARCHREQFLAGS) \
+-$(KLIBCOPTFLAGS) $(KLIBCSTACKFLGS) $(KLIBCWARNFLAGS)
++$(KLIBCOPTFL
Bug#1016924: hddemux: FTBFS on ppc64el
Dear Maintainer, Attached is what we uploaded for Ubuntu, just in case it helps. -Dan diff -Nru hddemux-0.5/debian/control hddemux-0.5/debian/control --- hddemux-0.5/debian/control 2022-01-31 10:56:12.0 -0700 +++ hddemux-0.5/debian/control 2022-01-31 10:56:12.0 -0700 @@ -7,7 +7,7 @@ debhelper-compat (= 13), gnutls-bin [!arm64] , knot-dnsutils [!arm64] , - knot-resolver [!arm64 !s390x] , + knot-resolver [!arm64 !ppc64el !s390x] , libsystemd-dev, libuv1-dev, nginx-light [!arm64] , diff -Nru hddemux-0.5/debian/rules hddemux-0.5/debian/rules --- hddemux-0.5/debian/rules2022-01-31 10:56:12.0 -0700 +++ hddemux-0.5/debian/rules2022-01-31 10:56:12.0 -0700 @@ -1,7 +1,7 @@ #!/usr/bin/make -f export DEB_BUILD_MAINT_OPTIONS = hardening=+all -KRESD_BROKEN_ARCHES := arm64 s390x +KRESD_BROKEN_ARCHES := arm64 s390x ppc64el ifneq (, $(filter $(DEB_HOST_ARCH), $(KRESD_BROKEN_ARCHES))) DEB_BUILD_OPTIONS += nocheck endif
Bug#1016924: hddemux: FTBFS on ppc64el
Package: hddemux Version: 0.5-1 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu kinetic Dear Maintainer, Due to recent changes to knot-resolver to drop ppc64el builds, hddemux will FTBFS on ppc64el. I suggest adding ppc64el to the KRESD_BROKEN_ARCHES list. -Dan
Bug#1016699: knot-resolver: Fails autopkgtest on ppc64el
Package: knot-resolver Version: 5.4.4-1 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu kinetic Dear Maintainer, Unfortunately, the recent -4 change to remove ppc64el builds was incomplete. There is another entry, later in the control file. -Dan
Bug#1004629: motion: FTBFS with ffmpeg 5.0
Dear Maintainer,
I backported the work merged upstream around ffmpeg 5. Please see attached.
This was sufficient to address the FTBFS both for Sid and Ubuntu Kinetic.
-Dan
Description: Backport ffmpeg 5 fixes.
Author: Dan Bungert
Origin: https://github.com/Motion-Project/motion/pull/1351/commits/fc9ed24c467006a463684f7db2f760a61f1eebe0
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1982886
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004629
Forwarded: not-needed
Last-Update: 2022-07-26
--- a/src/ffmpeg.c
+++ b/src/ffmpeg.c
@@ -340,7 +340,7 @@
if (ffmpeg->tlapse == TIMELAPSE_APPEND){
ffmpeg->oc->oformat = av_guess_format ("mpeg2video", NULL, NULL);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_MPEG2VIDEO;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_MPEG2VIDEO;
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mpg",basename);
if ((!ffmpeg->oc->oformat) ||
(retcd < 0) || (retcd >= PATH_MAX)){
@@ -362,7 +362,7 @@
if (strcmp(codec_name, "msmpeg4") == 0) {
ffmpeg->oc->oformat = av_guess_format("avi", NULL, NULL);
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.avi",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_MSMPEG4V2;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_MSMPEG4V2;
}
if (strcmp(codec_name, "swf") == 0) {
@@ -373,13 +373,13 @@
if (strcmp(codec_name, "flv") == 0) {
ffmpeg->oc->oformat = av_guess_format("flv", NULL, NULL);
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.flv",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_FLV1;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_FLV1;
}
if (strcmp(codec_name, "ffv1") == 0) {
ffmpeg->oc->oformat = av_guess_format("avi", NULL, NULL);
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.avi",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_FFV1;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_FFV1;
}
if (strcmp(codec_name, "mov") == 0) {
@@ -390,19 +390,19 @@
if (strcmp(codec_name, "mp4") == 0) {
ffmpeg->oc->oformat = av_guess_format("mp4", NULL, NULL);
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mp4",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_H264;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_H264;
}
if (strcmp(codec_name, "mkv") == 0) {
ffmpeg->oc->oformat = av_guess_format("matroska", NULL, NULL);
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mkv",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_H264;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_H264;
}
if (strcmp(codec_name, "hevc") == 0) {
ffmpeg->oc->oformat = av_guess_format("mp4", NULL, NULL);
retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mp4",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_HEVC;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_HEVC;
}
//Check for valid results
@@ -422,7 +422,7 @@
return -1;
}
-if (ffmpeg->oc->oformat->video_codec == MY_CODEC_ID_NONE) {
+if (ffmpeg->oc->video_codec_id == MY_CODEC_ID_NONE) {
MOTION_LOG(ERR, TYPE_ENCODER, NO_ERRNO, _("Could not get the codec"));
ffmpeg_free_context(ffmpeg);
free(codec_name);
@@ -721,7 +721,7 @@
} else {
ffmpeg->codec = avcodec_find_encoder_by_name(&ffmpeg->codec_name[codec_name_len+1]);
if ((ffmpeg->oc->oformat) && (ffmpeg->codec != NULL)) {
-ffmpeg->oc->oformat->video_codec = ffmpeg->codec->id;
+ffmpeg->oc->video_codec_id = ffmpeg->codec->id;
} else if (ffmpeg->codec == NULL) {
MOTION_LOG(WRN, TYPE_ENCODER, NO_ERRNO
,_("Preferred codec %s not found")
@@ -730,7 +730,7 @@
}
}
if (!ffmpeg->codec)
-ffmpeg->codec = avcodec_find_encoder(ffmpeg->oc->oformat->video_codec);
+ffmpeg->codec =
Bug#1010095: performous: FTBFS on ppc64el
Just saw the existing merge request. Oh well, I guess I can treat this as +1 for merging https://salsa.debian.org/games-team/performous/-/merge_requests/1 .
Bug#1010095: performous: FTBFS on ppc64el
Hi Maintainer, I was able to get it building again, at least on the ppc64el machine I tested, by not using with -mno-altivec. Builds both with Sid and Ubuntu Kinetic, if you use my patch from bug 1004616 and no longer set -mno-altivec. See also this commit: https://salsa.debian.org/games-team/performous/-/commit/de72e1dfae743adb65a444341872bda06d6941e7 Is -mno-altivec still required? -Dan
Bug#1004616: performous: FTBFS with ffmpeg 5.0
Dear Maintainer,
I did a test build using the version of performous in experimental on Sid and
Ubuntu Kinetic. I found that it continues to have a const-related build
failure.
Upstream commit
https://github.com/performous/performous/pull/752/commits/80d5b08d34a97db16fe12f82e9060570087ef0f0
is a step in the right direction, but in this older codebase needed more.
Please see attached for a patch that fixes build of the version in experimental
with Sid and Ubuntu Kinetic.
-Dan
Description: constify AVCodec* for ffmpeg 5 compat
Origin: https://github.com/performous/performous/pull/752/commits/80d5b08d34a97db16fe12f82e9060570087ef0f0
Author: Dan Bungert
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1982781
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004616
Forwarded: not-needed
Last-Update: 2022-07-25
Extended above commit to handle an additional const.
--- a/game/ffmpeg.cc
+++ b/game/ffmpeg.cc
@@ -96,10 +96,16 @@
if (avformat_find_stream_info(m_formatContext, nullptr) < 0) throw std::runtime_error("Cannot find stream information");
m_formatContext->flags |= AVFMT_FLAG_GENPTS;
// Find a track and open the codec
+#if (LIBAVFORMAT_VERSION_INT) >= (AV_VERSION_INT(59, 0, 100))
+ const
+#endif
AVCodec* codec = nullptr;
m_streamId = av_find_best_stream(m_formatContext, (AVMediaType)m_mediaType, -1, -1, &codec, 0);
if (m_streamId < 0) throw std::runtime_error("No suitable track found");
+#if (LIBAVFORMAT_VERSION_INT) >= (AV_VERSION_INT(59, 0, 100))
+ const
+#endif
#if (LIBAVCODEC_VERSION_INT) >= (AV_VERSION_INT(57,0,0))
AVCodec* pCodec = avcodec_find_decoder(m_formatContext->streams[m_streamId]->codecpar->codec_id);
AVCodecContext* pCodecCtx = avcodec_alloc_context3(pCodec);
Bug#1004805: xmms2: FTBFS with ffmpeg 5.0
Dear Maintainer,
I backported the work merged upstream around ffmpeg 5. Please see attached.
This was sufficient to address the FTBFS both for Sid and Ubuntu Kinetic.
-Dan
Description: ffmpeg 5 compat
Author: Dan Bungert
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/xmms2/+bug/1982419
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004805
Forwarded: not-needed
Origin: https://github.com/xmms2/xmms2-devel/pull/11
Last-Update: 2022-07-20
diff --git a/src/plugins/avcodec/avcodec.c b/src/plugins/avcodec/avcodec.c
index 23fd4615e..a5c5aa0f4 100644
--- a/src/plugins/avcodec/avcodec.c
+++ b/src/plugins/avcodec/avcodec.c
@@ -31,6 +31,7 @@
typedef struct {
AVCodecContext *codecctx;
+ AVPacket packet;
guchar *buffer;
guint buffer_length;
@@ -149,13 +150,12 @@ xmms_avcodec_init (xmms_xform_t *xform)
data->buffer = g_malloc (AVCODEC_BUFFER_SIZE);
data->buffer_size = AVCODEC_BUFFER_SIZE;
data->codecctx = NULL;
+ data->packet.size = 0;
data->read_out_frame = av_frame_alloc ();
xmms_xform_private_data_set (xform, data);
- avcodec_register_all ();
-
mimetype = xmms_xform_indata_get_str (xform,
XMMS_STREAM_TYPE_MIMETYPE);
data->codec_id = mimetype + strlen ("audio/x-ffmpeg-");
@@ -466,45 +466,37 @@ FF_INPUT_BUFFER_PADDING_SIZE long.
static gint
xmms_avcodec_internal_decode_some (xmms_avcodec_data_t *data)
{
- int got_frame = 0;
- gint bytes_read = 0;
- AVPacket packet;
+ int rc = 0;
- av_init_packet (&packet);
- packet.data = data->buffer;
- packet.size = data->buffer_length;
+ if (data->packet.size == 0) {
+ av_init_packet (&data->packet);
+ data->packet.data = data->buffer;
+ data->packet.size = data->buffer_length;
- /* clear buffers and reset fields to defaults */
- av_frame_unref (data->read_out_frame);
-
- bytes_read = avcodec_decode_audio4 (
- data->codecctx, data->read_out_frame, &got_frame, &packet);
+ rc = avcodec_send_packet(data->codecctx, &data->packet);
+ if (rc == AVERROR_EOF)
+ rc = 0;
+ }
- /* The DTS decoder of ffmpeg is buggy and always returns
- * the input buffer length, get frame length from header */
- /* FIXME: Is still true? */
- if (!strcmp (data->codec_id, "dca") && bytes_read > 0) {
- bytes_read = ((int)data->buffer[5] << 12) |
- ((int)data->buffer[6] << 4) |
- ((int)data->buffer[7] >> 4);
- bytes_read = (bytes_read & 0x3fff) + 1;
+ if (rc == 0) {
+ rc = avcodec_receive_frame(data->codecctx, data->read_out_frame);
+ if (rc < 0) {
+ data->packet.size = 0;
+ data->buffer_length = 0;
+ if (rc == AVERROR(EAGAIN)) rc = 0;
+ else if (rc == AVERROR_EOF) rc = 1;
+ }
+ else
+ rc = 1;
}
- if (bytes_read < 0 || bytes_read > data->buffer_length) {
+ if (rc < 0) {
+ data->packet.size = 0;
XMMS_DBG ("Error decoding data!");
return -1;
}
- if (bytes_read < data->buffer_length) {
- data->buffer_length -= bytes_read;
- g_memmove (data->buffer,
- data->buffer + bytes_read,
- data->buffer_length);
- } else {
- data->buffer_length = 0;
- }
-
- return got_frame ? 1 : 0;
+ return rc;
}
static void
diff --git a/src/plugins/avcodec/wscript b/src/plugins/avcodec/wscript
index 00b182b24..4b6227437 100644
--- a/src/plugins/avcodec/wscript
+++ b/src/plugins/avcodec/wscript
@@ -1,7 +1,7 @@
from waftools.plugin import plugin
## Code fragments for configuration
-avcodec_decode_audio4_fragment = """
+avcodec_send_packet_fragment = """
#ifdef HAVE_LIBAVCODEC_AVCODEC_H
# include "libavcodec/avcodec.h"
#else
@@ -9,11 +9,9 @@ avcodec_decode_audio4_fragment = """
#endif
int main(void) {
AVCodecContext *ctx;
-AVFrame *frame;
-int got_frame;
AVPacket *pkt;
-avcodec_decode_audio4 (ctx, frame, &got_frame, pkt);
+avcodec_send_packet (ctx, pkt);
return 0;
}
@@ -40,12 +38,12 @@ def plugin_configure(conf):
conf.check_cc(header_name="avcodec.h", uselib="avcodec", type="cshlib", mandatory=False)
conf.check_cc(header_name="libavcodec/avcodec.h", uselib="avcodec", type="cshlib", mandatory=False)
-# mandatory function avcodec_decode_audio4 available since
-# * ffmpeg: commit e4de716, lavc 53.40.0, release 0.9
-# * libav: commit 0eea212, lavc 53.25.0, release 0.8
-conf.check_cc(fragment=avcodec_decode_audio4_fragment, uselib="avcodec",
- uselib_store="avcodec_decode_audio4",
- msg="Checking for function avcodec_decode_audio4", mandatory=True)
+# mandatory function avcodec_send_packet available since
+# * ffmpeg: commit 7fc329e, lavc 57.37.100, release 3.1
+# *
Bug#1004797: xpra: FTBFS with ffmpeg 5.0
Dear Maintainer,
I backported the work done by upstream around ffmpeg 5. Please see attached.
This was sufficient to address the FTBFS both for Sid and Ubuntu Kinetic.
-Dan
Subject: Backport ffmpeg 5 fixes
Author: Dan Bungert
Origin: https://github.com/Xpra-org/xpra
Bug: https://github.com/Xpra-org/xpra/pull/3242
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1982418
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004797
Forwarded: not-needed
Last-Update: 2022-07-20
Backport fixes from Antoine Martin upstream:
* b66a358fc31852ad246a9956dfa5f09a0f2b5274
* 5058864909fdf76652d20c3d555bd91667762f88
* f70e01d6e66245b689c11433abef9c51d345452e
* 19060163bc0a0174dafce40ee7c176e8c7fbb9df
--- a/xpra/codecs/enc_ffmpeg/encoder.pyx
+++ b/xpra/codecs/enc_ffmpeg/encoder.pyx
@@ -203,7 +203,7 @@
int width
int height
AVPixelFormat pix_fmt
-int thread_safe_callbacks
+#int thread_safe_callbacks
int thread_count
int thread_type
int flags
@@ -286,7 +286,7 @@
AVCodecID AV_CODEC_ID_AAC
#init and free:
-AVCodec *avcodec_find_encoder(AVCodecID id)
+const AVCodec *avcodec_find_encoder(AVCodecID id)
AVCodecContext *avcodec_alloc_context3(const AVCodec *codec)
int avcodec_open2(AVCodecContext *avctx, const AVCodec *codec, AVDictionary **options)
int avcodec_send_frame(AVCodecContext *avctx,const AVFrame *frame) nogil
@@ -367,10 +367,8 @@
int AVFMT_FLAG_DISCARD_CORRUPT #Discard frames marked corrupted
int AVFMT_FLAG_FLUSH_PACKETS#Flush the AVIOContext every packet
int AVFMT_FLAG_BITEXACT
-int AVFMT_FLAG_MP4A_LATM#Enable RTP MP4A-LATM payload
int AVFMT_FLAG_SORT_DTS #try to interleave outputted packets by dts (using this flag can slow demuxing down)
int AVFMT_FLAG_PRIV_OPT #Enable use of private options by delaying codec open (this could be made default once all code is converted)
-int AVFMT_FLAG_KEEP_SIDE_DATA #Don't merge side data but keep it separate.
int AVFMT_FLAG_FAST_SEEK#Enable fast, but inaccurate seeks for some formats
int AVFMT_NOFILE#Demuxer will use avio_open, no opened file should be provided by the caller
@@ -509,10 +507,8 @@
AVFMT_FLAG_DISCARD_CORRUPT : "DISCARD_CORRUPT",
AVFMT_FLAG_FLUSH_PACKETS : "FLUSH_PACKETS",
AVFMT_FLAG_BITEXACT: "BITEXACT",
-AVFMT_FLAG_MP4A_LATM : "MP4A_LATM",
AVFMT_FLAG_SORT_DTS: "SORT_DTS",
AVFMT_FLAG_PRIV_OPT: "PRIV_OPT",
-AVFMT_FLAG_KEEP_SIDE_DATA : "KEEP_SIDE_DATA",
AVFMT_FLAG_FAST_SEEK : "FAST_SEEK",
}
@@ -747,7 +743,7 @@
cdef object muxer_format
cdef object file
#video:
-cdef AVCodec *video_codec
+cdef const AVCodec *video_codec
cdef AVStream *video_stream
cdef AVCodecContext *video_ctx
cdef AVPixelFormat pix_fmt
@@ -759,7 +755,7 @@
cdef object encoding
cdef object profile
#audio:
-cdef AVCodec *audio_codec
+cdef const AVCodec *audio_codec
cdef AVStream *audio_stream
cdef AVCodecContext *audio_ctx
cdef uint8_t ready
@@ -902,7 +898,7 @@
self.video_ctx.height = self.height
self.video_ctx.bit_rate = max(20, self.width*self.height*4) #4 bits per pixel
self.video_ctx.pix_fmt = self.pix_fmt
-self.video_ctx.thread_safe_callbacks = 1
+#self.video_ctx.thread_safe_callbacks = 1
#if oformat.flags & AVFMT_GLOBALHEADER:
if self.encoding not in ("mpeg1", "mpeg2"):
self.video_ctx.thread_type = THREAD_TYPE
--- a/xpra/codecs/dec_avcodec2/decoder.pyx
+++ b/xpra/codecs/dec_avcodec2/decoder.pyx
@@ -71,7 +71,7 @@
int width
int height
AVPixelFormat pix_fmt
-int thread_safe_callbacks
+#int thread_safe_callbacks
int thread_count
int thread_type
int flags
@@ -87,7 +87,7 @@
AVCodecID AV_CODEC_ID_MPEG2VIDEO
#init and free:
-AVCodec *avcodec_find_decoder(AVCodecID id)
+const AVCodec *avcodec_find_decoder(AVCodecID id)
AVCodecContext *avcodec_alloc_context3(const AVCodec *codec)
int avcodec_open2(AVCodecContext *avctx, const AVCodec *codec, AVDictionary **options)
AVFrame* av_frame_alloc()
@@ -95,7 +95,8 @@
int avcodec_close(AVCodecContext *avctx)
#actual decoding:
-void av_init_packet(AVPacket *pkt) nogil
+AVPacket *av_packet_alloc() nogil
+void av_packet_free(AVPacket **avpkt)
void avcodec_get_frame_defaults(AVFrame *frame) nogil
int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt) nogil
int avcodec_receive_frame(AVCodecContext *avctx, AVFrame *frame) nogil
@@ -293,7 +294,7 @@
It also handles reconstructing a single ImageWrapper
constructed from
Bug#1010535: cyrus-imapd: FTBFS against openssl 3
I ended up sending a PR to upstream anyhow, even though it was tested against the source from Debian. We'll see that they say. https://github.com/cyrusimap/cyrus-imapd/pull/4075 -Dan
Bug#1010578: osmo-mgw: FTBFS if systemd is in build environment
Package: osmo-mgw
Version: 1.9.0+dfsg1-3
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic
Dear Maintainer,
If systemd is present in the build environment, the following output will be
observed during build:
dh_missing: warning: lib/systemd/system/osmo-mgw.service exists in debian/tmp
but is not installed to anywhere
dh_missing: error: missing files, aborting
This appears to be due to an unexpected upstream systemd service file, that is
then not covered by the existing debhelper commands.
There are several options to avoid this, including
* add the entry to not-installed
* configure with argument --with-systemdsystemunitdir=no, which cause the
install step to not provide the upstream systemd service file
* adjust the package to use the upstream systemd service file
I propose using the --with-systemdsystemunitdir=no configuration. See below.
-Dan
diff -Nru osmo-mgw-1.9.0+dfsg1/debian/rules osmo-mgw-1.9.0+dfsg1/debian/rules
--- osmo-mgw-1.9.0+dfsg1/debian/rules 2022-03-16 14:59:47.0 -0600
+++ osmo-mgw-1.9.0+dfsg1/debian/rules 2022-05-04 13:34:46.0 -0600
@@ -15,6 +15,10 @@
%:
dh $@ --with autoreconf
+override_dh_auto_configure:
+ # Use the packaging-provided systemd unit file
+ dh_auto_configure -- --with-systemdsystemunitdir=no
+
override_dh_auto_test:
dh_auto_test || (find . -name testsuite.log -exec cat {} \; ; false)
Bug#1010535: cyrus-imapd: FTBFS against openssl 3
Package: cyrus-imapd
Version: 3.6.0~beta2-2
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic
Dear Maintainer,
When building against openssl 3 from experimental, cyrus-imapd will fail in
unit test at build time. This appears to be related to related to the warning
listed at
https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_base_id.html
which suggests using
https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_is_a.html
instead.
In these failing cases, EVP_PKEY_base_id is returning 0, which fails to match
the nid that is being compared against.
I have a patch which converts usage of EVP_PKEY_base_id to EVP_PKEY_is_a, which
allows builds against OpenSSL 3 to pass for both Ubuntu Kinetic and Debian Sid.
Please see attached. I also updated another usage of EVP_PKEY_base_id which I
believe will be incorrect under OpenSSL 3 but that doesn't seem to be caught by
current tests.
Ordinarly at this point I would forward to upstream, but I prefer to do so
first by reproducing the failures with raw upstream source which is is having
unrelated build problems for me. So I'm starting this way.
(also filed at https://launchpad.net/bugs/1971469)
-Dan
Description: OpenSSL 3 compatibility fix for EVP_PKEY_base_id usage
The WARNING section of the EVP_PKEY_base_id manpage in OpenSSL 3 says that
EVP_PKEY_base_id is "only reliable with EVP_PKEYs that have been assigned an
internal key with EVP_PKEY_assign_*", and the usage here of base_id seems to
be without a EVP_PKEY_assign usage.
This same warning points to EVP_PKEY_is_a, which seems fine for this purpose
but is part of OpenSSL 3.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/cyrus-imapd/+bug/1971469
Last-Update: 2022-05-03
--- a/imap/http_jwt.c
+++ b/imap/http_jwt.c
@@ -120,10 +120,15 @@
EVP_PKEY *pkey = PEM_read_bio_PUBKEY(bp, NULL, NULL, NULL);
if (pkey) {
+#if OPENSSL_VERSION_NUMBER >= 0x3000L
+if (!EVP_PKEY_is_a(pkey, "RSA")) {
+xsyslog(LOG_ERR, "Unsupported public key", NULL);
+#else
int nid = EVP_PKEY_base_id(pkey);
if (nid != EVP_PKEY_RSA) {
xsyslog(LOG_ERR, "Unsupported public key",
"type=<%s>", OBJ_nid2ln(nid));
+#endif
EVP_PKEY_free(pkey);
pkey = NULL;
}
@@ -318,6 +323,25 @@
return 1;
}
+static int validate_pkey_type(struct jwt *jwt, EVP_PKEY *pkey)
+{
+if (!jwt->nid)
+return 0;
+
+if (jwt->nid == EVP_PKEY_base_id(pkey))
+return 1;
+
+#if OPENSSL_VERSION_NUMBER >= 0x3000L
+if (jwt->nid == EVP_PKEY_HMAC && EVP_PKEY_is_a(pkey, "HMAC"))
+return 1;
+
+if (jwt->nid == EVP_PKEY_RSA && EVP_PKEY_is_a(pkey, "RSA"))
+return 1;
+#endif
+
+return 0;
+}
+
static int validate_signature(struct jwt *jwt)
{
buf_reset(&jwt->buf);
@@ -339,7 +363,7 @@
EVP_PKEY *pkey = ptrarray_nth(&pkeys, i);
EVP_MD_CTX_reset(ctx);
-if (jwt->nid != EVP_PKEY_base_id(pkey))
+if (!validate_pkey_type(jwt, pkey))
continue;
if (jwt->nid == EVP_PKEY_HMAC) {
Bug#1006743: SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats
Package: python-systemd Version: 234-3build6 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu jammy Dear Maintainer, This bug report was also filed in Ubuntu and can be found at https://launchpad.net/bugs/1963582 The description, from Dan Bungert, follows: Attempting to use the Reader class with python3.10, such as documented in the example at https://www.freedesktop.org/software/systemd/python-systemd/journal.html?highlight=reader#systemd.journal.Reader, results in the following traceback File "/usr/lib/python3/dist-packages/systemd/journal.py", line 376, in this_boot self.add_match(_BOOT_ID=bootid) File "/usr/lib/python3/dist-packages/systemd/journal.py", line 244, in add_match super(Reader, self).add_match(arg) SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats I have sent a MR that should help, using a cherry-picked commit from upstream. https://salsa.debian.org/systemd-team/python-systemd/-/merge_requests/2 -Dan
Bug#1006374: graphicsmagick breaks ruby-mini-magick autopkgtest: Failure/Error: expect(subject["EXIF:Flash"]).to eq "0"
Hi All, I investigated debbug 1006374 today and found that revision 16603:ba930c1fc380 of graphicsmagick appears to be causing the regression to ruby-mini-magick. A rebuild of graphicsmagick minus this commit allows ruby-mini-magick to pass autopkgtest. I did my testing against Ubuntu but expect the same results for Debian. changeset: 16603:ba930c1fc380 summary: JPEG: Implement more efficient way to append JPEG profile chunks. -Dan
Bug#1005145: oz: FTBFS against python 3.10
Package: oz Version: 0.17.0-4 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu jammy Dear Maintainer, This bug report was also filed in Ubuntu and can be found at https://launchpad.net/bugs/1960273 When oz is triggered with python3.10 for autopkgtest, it will fail due to the migration of some collections items to collections.abc. See also the patch that I have sent upstream: https://github.com/clalancette/oz/pull/292 -Dan
Bug#1004707: hydra: FTBFS against openssl 3.0
Package: hydra
Version: 9.2-1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1959622
Hydra will FTBFS when building against openssl 3.0 for want of a INT_MAX
definition. I confirmed this in a sid container with openssl from
experimental.
In file included from hydra-mod.c:8:
/usr/include/openssl/err.h: In function ‘ERR_GET_LIB’:
/usr/include/openssl/err.h:243:9: error: ‘INT_MAX’ undeclared
(first use in this function)
243 | if (ERR_SYSTEM_ERROR(errcode))
/usr/include/openssl/err.h:31:1: note: ‘INT_MAX’ is defined in header
‘’; did you forget to ‘#include ’?
limits.h does get included, but a conflict between the hydra configure file and
the de-facto package layout of libmemcached-dev means that the wrong limits.h
file, then one from memcached, is included.
Also sent upstream - https://github.com/vanhauser-thc/thc-hydra/pull/718
See attached patch.
-Dan
diff -Nru hydra-9.2/debian/patches/10_memcached_include.diff
hydra-9.2/debian/patches/10_memcached_include.diff
--- hydra-9.2/debian/patches/10_memcached_include.diff 1969-12-31
17:00:00.0 -0700
+++ hydra-9.2/debian/patches/10_memcached_include.diff 2022-01-31
14:45:37.0 -0700
@@ -0,0 +1,28 @@
+Description: Adjust memcached include dir lookup to not shadow limits.h
+ Compilation against openssl 3.0 causes a failure to find INT_MAX, despite the
+ openssl headers including limits.h. However, the fact that the
+ libmemcached-dev package provides both /usr/include/libmemcached{,-1.0}
+ directories, both of which contain memcached.h, mean that MCACHED_IPATH ends
+ up set to the libmemcached-1.0 one, which contains a limits.h, which shadows
+ /usr/include/limits.h.
+ Don't do that.
+Author: Dan Bungert
+Bug-Ubuntu: https://launchpad.net/bugs/1959622
+Forwarded: https://github.com/vanhauser-thc/thc-hydra/pull/718
+Last-Update: 2022-01-31
+--- a/configure
b/configure
+@@ -998,11 +998,9 @@
+ if [ "X" = "X$MCACHED_IPATH" ]; then
+ if [ -f "$i/memcached.h" ]; then
+ MCACHED_IPATH="$i"
+-fi
+-if [ -f "$i/libmemcached/memcached.h" ]; then
++elif [ -f "$i/libmemcached/memcached.h" ]; then
+ MCACHED_IPATH="$i/libmemcached"
+-fi
+-if [ -f "$i/libmemcached-1.0/memcached.h" ]; then
++elif [ -f "$i/libmemcached-1.0/memcached.h" ]; then
+ MCACHED_IPATH="$i/libmemcached-1.0"
+ fi
+ fi
diff -Nru hydra-9.2/debian/patches/series hydra-9.2/debian/patches/series
--- hydra-9.2/debian/patches/series 2021-11-12 17:52:58.0 -0700
+++ hydra-9.2/debian/patches/series 2022-01-31 14:02:53.0 -0700
@@ -5,3 +5,4 @@
03_use_bin_path.diff
06_show_xhydra_build_output.diff
07_remove_troubled_files.diff
+10_memcached_include.diff
Bug#1004446: cdist: FTBFS against python 3.10
Package: cdist
Version: 6.9.4-1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1959330
autopkgtest will fail when python3.10 is used. Upstream has fixed relevant
things already, so here's a patch with those commits.
-Dan
diff -Nru cdist-6.9.4/debian/changelog cdist-6.9.4/debian/changelog
--- cdist-6.9.4/debian/changelog2021-02-07 00:45:26.0 -0700
+++ cdist-6.9.4/debian/changelog2022-01-27 11:45:53.0 -0700
@@ -1,3 +1,11 @@
+cdist (6.9.4-1.1) jammy; urgency=medium
+
+ * Cherry-pick 2 commits for python 3.10 compatibility
+* Fix version compare
+* Fix transition of some classes from collections to collections.abc
+
+ -- Dan Bungert Thu, 27 Jan 2022 11:45:53 -0700
+
cdist (6.9.4-1) unstable; urgency=medium
* QA upload.
diff -Nru cdist-6.9.4/debian/patches/collections-abc.patch
cdist-6.9.4/debian/patches/collections-abc.patch
--- cdist-6.9.4/debian/patches/collections-abc.patch1969-12-31
17:00:00.0 -0700
+++ cdist-6.9.4/debian/patches/collections-abc.patch2022-01-27
11:45:53.0 -0700
@@ -0,0 +1,36 @@
+Description: Python 3.10: collections.X -> collections.abc.X
+Origin:
https://code.ungleich.ch/ungleich-public/cdist/commit/3a321469a8ba5aea55220bd70bd4900de732e917
+Author: Timothée Floure
+Forwarded: 'not-needed'
+Last-Update: 2022-01-27
+--- a/cdist/integration.py
b/cdist/integration.py
+@@ -84,7 +84,7 @@
+ """
+ if isinstance(host, str):
+ hosts = [host, ]
+-elif isinstance(host, collections.Iterable):
++elif isinstance(host, collections.abc.Iterable):
+ hosts = host
+ else:
+ raise cdist.Error('Invalid host argument: {}'.format(host))
+--- a/cdist/util/fsproperty.py
b/cdist/util/fsproperty.py
+@@ -33,7 +33,7 @@
+ return 'Absolute path required, got: %s' % self.path
+
+
+-class FileList(collections.MutableSequence):
++class FileList(collections.abc.MutableSequence):
+ """A list that stores it's state in a file.
+
+ """
+@@ -102,7 +102,7 @@
+ self.__write(lines)
+
+
+-class DirectoryDict(collections.MutableMapping):
++class DirectoryDict(collections.abc.MutableMapping):
+ """A dict that stores it's items as files in a directory.
+
+ """
diff -Nru cdist-6.9.4/debian/patches/series cdist-6.9.4/debian/patches/series
--- cdist-6.9.4/debian/patches/series 2021-02-07 00:45:26.0 -0700
+++ cdist-6.9.4/debian/patches/series 2022-01-27 11:45:53.0 -0700
@@ -1 +1,3 @@
explicitly-specify-path-one-remote-side.patch
+collections-abc.patch
+version-compare.patch
diff -Nru cdist-6.9.4/debian/patches/version-compare.patch
cdist-6.9.4/debian/patches/version-compare.patch
--- cdist-6.9.4/debian/patches/version-compare.patch1969-12-31
17:00:00.0 -0700
+++ cdist-6.9.4/debian/patches/version-compare.patch2022-01-27
11:45:53.0 -0700
@@ -0,0 +1,33 @@
+Description: [bin/cdist] Fix Python version check
+Origin:
https://code.ungleich.ch/ungleich-public/cdist/commit/1c047353a95e7ac079ccf89af8fc232451b8f891
+Author: Dennis Camera
+Forwarded: 'not-needed'
+Last-Update: 2021-04-17
+--- a/bin/cdist
b/bin/cdist
+@@ -72,9 +72,11 @@
+
+
+ if __name__ == "__main__":
+-if sys.version < cdist.MIN_SUPPORTED_PYTHON_VERSION:
+-print('Python >= {} is required on the source host.'.format(
+-cdist.MIN_SUPPORTED_PYTHON_VERSIO), file=sys.stderr)
++if sys.version_info[:3] < cdist.MIN_SUPPORTED_PYTHON_VERSION:
++print(
++'Python >= {} is required on the source host.'.format(
++".".join(map(str, cdist.MIN_SUPPORTED_PYTHON_VERSION))),
++file=sys.stderr)
+ sys.exit(1)
+
+ exit_code = 0
+--- a/cdist/__init__.py
b/cdist/__init__.py
+@@ -64,7 +64,7 @@
+ REMOTE_CMDS_CLEANUP_PATTERN = "ssh -o User=root -O exit -S {}"
+
+
+-MIN_SUPPORTED_PYTHON_VERSION = '3.5'
++MIN_SUPPORTED_PYTHON_VERSION = (3, 5)
+
+
+ class Error(Exception):
Bug#1003307: restfuldb: FTBFS against sqlite3 3.37 or newer
On Mon, Jan 10, 2022 at 12:06:31PM +0200, Andrius Merkys wrote: > On 2022-01-08 00:02, Dan Bungert wrote: > > When built against sqlite 3.37 or newer, the build will fail in test. > > tests/cases/Database.pm_001.sh:FAILED: > > 2c2 > > < 'image' => 'blob' > > --- > > > 'image' => 'BLOB' > Your workaround works fine, but it may hide possible future regressions where > letter case is actually important. Since I am one of the upstream developers > I will see how this could be fixed upstream. Yes, that's entirely sensible. I came to a similar conclusion when I realized that the 'create table' statements in the premade db files needed an update to be compatible with both 3.37 and 3.36. -Dan
Bug#1003307: restfuldb: FTBFS against sqlite3 3.37 or newer
Package: restfuldb
Version: 0.15.2+dfsg-2
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1956798
When built against sqlite 3.37 or newer, the build will fail in test.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/restfuldb/20220107_080256_a18a5@/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/restfuldb/17950775/log.gz
tests/cases/Database.pm_001.sh:FAILED:
2c2
< 'image' => 'blob'
---
> 'image' => 'BLOB'
+many more of a similar nature.
As of sqlite 3.37.0, with FossilOrigin-Name:
d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f,
type names for 5 common types BLOB, INT, INTEGER, REAL, and TEXT will be
treated as if they were created in all uppercase.
My proposed workaround is the following. Due to the nature of the tests, any
sort of fixes to the test would in my opinion be best done upstream.
--- restfuldb-0.15.2+dfsg.orig/Makefile
+++ restfuldb-0.15.2+dfsg/Makefile
@@ -103,7 +103,7 @@ define can_run_test
endef
define diff_outputs
-diff -I 'Expires:\|Date:' ${OUTP_DIR}/$*.out -
+diff -i -I 'Expires:\|Date:' ${OUTP_DIR}/$*.out -
endef
define report_differences
-Dan
Bug#1003305: ruby-sqlite3: FTBFS against sqlite3 3.37 or newer
Package: ruby-sqlite3
Version: 1.4.2-3build1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1956796
The description, from Dan Bungert, follows:
When built against sqlite 3.37 or newer, the build will fail in test.
Examples:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/ruby-sqlite3/20220107_075823_1a1f3@/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-sqlite3/17951708/log.gz
TC_ResultSet#test_types
[/tmp/autopkgtest.J0NEKT/build.hEV/src/test/test_integration_resultset.rb:121]:
Expected: ["integer", "text"]
Actual: ["INTEGER", "TEXT"]
+2 more failures of a similar nature.
As of sqlite 3.37.0, with FossilOrigin-Name:
d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f,
type names for 5 common types BLOB, INT, INTEGER, REAL, and TEXT will be
treated as if they were created in all uppercase.
See attached for my proposed change for Ubuntu to address the test failures.
-Dan
diff -Nru ruby-sqlite3-1.4.2/debian/changelog
ruby-sqlite3-1.4.2/debian/changelog
--- ruby-sqlite3-1.4.2/debian/changelog 2021-12-03 15:07:08.0 -0700
+++ ruby-sqlite3-1.4.2/debian/changelog 2022-01-07 14:15:57.0 -0700
@@ -1,3 +1,9 @@
+ruby-sqlite3 (1.4.2-3ubuntu1) jammy; urgency=medium
+
+ * Adjust tests for compatibility with sqlite 3.37.0 or newer (LP: #1956796)
+
+ -- Dan Bungert Fri, 07 Jan 2022 14:15:57 -0700
+
ruby-sqlite3 (1.4.2-3build2) jammy; urgency=medium
* No-change upload due to ruby3.0 transition, remove ruby2.7 support.
diff -Nru ruby-sqlite3-1.4.2/debian/control ruby-sqlite3-1.4.2/debian/control
--- ruby-sqlite3-1.4.2/debian/control 2021-02-09 15:26:09.0 -0700
+++ ruby-sqlite3-1.4.2/debian/control 2022-01-07 14:15:57.0 -0700
@@ -1,7 +1,8 @@
Source: ruby-sqlite3
Section: ruby
Priority: optional
-Maintainer: Debian Ruby Team
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian Ruby Team
Uploaders: Dmitry Borodaenko
Build-Depends: debhelper-compat (= 13),
gem2deb (>= 1),
diff -Nru ruby-sqlite3-1.4.2/debian/patches/series
ruby-sqlite3-1.4.2/debian/patches/series
--- ruby-sqlite3-1.4.2/debian/patches/series2021-02-09 14:22:28.0
-0700
+++ ruby-sqlite3-1.4.2/debian/patches/series2022-01-06 17:05:49.0
-0700
@@ -1,2 +1,3 @@
use-slugs-in-faq.diff
drop-vendorizing-tasks.patch
+type-case.patch
diff -Nru ruby-sqlite3-1.4.2/debian/patches/type-case.patch
ruby-sqlite3-1.4.2/debian/patches/type-case.patch
--- ruby-sqlite3-1.4.2/debian/patches/type-case.patch 1969-12-31
17:00:00.0 -0700
+++ ruby-sqlite3-1.4.2/debian/patches/type-case.patch 2022-01-07
14:15:56.0 -0700
@@ -0,0 +1,77 @@
+Description: Use uppercase types for test
+ As of sqlite 3.37.0, with FossilOrigin-Name:
+ d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f,
+ type names for 5 common types BLOB, INT, INTEGER, REAL, and TEXT will be
+ treated as if they were created in all uppercase. This patch does two things
+ about this:
+ 1) Adjust expected types to upper case, as that will always be what newer
+ sqlite actually does for these 5 types
+ 2) adjust created tables to use upper case type names, so that pre-3.37 sqlite
+ uses the type name strings expected by the tests
+Author: Dan Bungert
+Bug-Ubuntu: https://launchpad.net/bugs/1956796
+Forwarded: https://github.com/sparklemotion/sqlite3-ruby/pull/304 ; PR comment
+Last-Update: 2022-01-07
+--- a/test/test_database.rb
b/test/test_database.rb
+@@ -268,12 +268,12 @@
+
+ def test_table_info
+ db = SQLite3::Database.new(':memory:', :results_as_hash => true)
+- db.execute("create table foo ( a integer primary key, b text )")
++ db.execute("create table foo ( a INTEGER primary key, b TEXT )")
+ info = [{
+ "name" => "a",
+ "pk" => 1,
+ "notnull"=> 0,
+-"type" => "integer",
++"type" => "INTEGER",
+ "dflt_value" => nil,
+ "cid"=> 0
+ },
+@@ -281,7 +281,7 @@
+ "name" => "b",
+ "pk" => 0,
+ "notnull"=> 0,
+-"type" => "text",
++"type" => "TEXT",
+ "dflt_value" => nil,
+ "cid"=> 1
+ }]
+--- a/test/test_integration.rb
b/test/test_integration.rb
+@@ -34,11 +34,11 @@
+
+ def test_table_info_without_defaults_for_version_3_3_8_and_higher
+ @db.transaction do
+- @db.execute "create table no_defaults_test ( a integer defa
Bug#997756: python-meshplex: FTBFS: sed: no input files
tags 997756 patch thanks Hi, I ran across this FTBFS today and investigated. Here's a patch. The forkme sed now appears unneeded, and the other one needs a URL update. -Dan diff -Nru python-meshplex-0.15.13/debian/rules python-meshplex-0.15.13/debian/rules --- python-meshplex-0.15.13/debian/rules 2021-03-16 04:39:31.0 -0600 +++ python-meshplex-0.15.13/debian/rules 2021-11-30 15:35:13.0 -0700 @@ -4,6 +4,7 @@ #export DH_VERBOSE = 1 export PYBUILD_NAME=meshplex +latestjs=https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js %: dh $@ --with python3,sphinxdoc --buildsystem=pybuild @@ -21,5 +22,4 @@ override_dh_sphinxdoc-indep: dh_sphinxdoc -i - grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js"; debian/python-meshplex-doc/usr/share/doc/python-meshplex-doc/* -r --files-with-matches | xargs sed "s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file://usr/share/javascript/mathjax/unpacked/latest.js|g" -i - grep "https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png"; debian/python-meshplex-doc/usr/share/doc/python-meshplex-doc/* -r --files-with-matches | xargs sed "s|src=\"https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png|src=\"_static/forkme_right_darkblue_121621.png|g" -i + grep "$(latestjs)" debian/python-meshplex-doc/usr/share/doc/python-meshplex-doc/* -r --files-with-matches | xargs sed "s|src=\"$(latestjs)|src=\"file://usr/share/javascript/mathjax/unpacked/latest.js|g" -i
Bug#993620: vip-manager: test failure with some network configurations
Package: vip-manager
Version: 1.0.1-4
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish
Dear Maintainer,
vip-manager behavior_test can fail, depending on the device network
configuration. If the test device has a network device of type ether
and a zero hardware address, and it selects this network device as the
one to use, the tests will fail.
Example failure:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/armhf/v/vip-manager/20210901_213607_5779b@/log.gz
2021/09/01 21:35:37 Problems with generating the virtual ip manager: Cannot run
vip-manager on the loopback device
as its hardware address is the local address (00:00:00:00:00:00),
which prohibits sending of gratuitous ARP messages
Here is abbreviated output of 'ip link show' for one such test device:
3: gretap0@NONE: mtu 1476 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
44262: eth0@if44263: mtu 1458 qdisc noqueue
state UP mode DEFAULT group default qlen 1000
link/ether 00:16:3e:0f:a3:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
In this example, gretap0 will be the chosen network device, but will
fail at runtime of vip-manager due to the all-zeros mac address.
Instead, eth0 should be chosen.
Please see the attached patch, which I will be looking to get integrated
to Ubuntu, which seems to address the above problem for Ubuntu armhf
autopkgtest.
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1942375
-Dan
Description: Improved test device selection
Author: Dan Bungert
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1942375
Last-Update: 2021-09-03
--- a/test/behaviour_test.sh
+++ b/test/behaviour_test.sh
@@ -7,9 +7,29 @@
NC='\033[0m' # No Color
# testing parameters
-dev=`ip link show | grep -B1 ether | cut -d ":" -f2 | head -n1 | cut -d " " -f2 | sed s/@.*//`
vip=10.0.2.123
+function get_dev {
+# select a suitable device for testing purposes
+# * a device that is an "ether"
+# * and isn't a nil hardware address
+
+# https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
+ARPHRD_ETHER=1
+
+for dev in /sys/class/net/* ; do
+test ! -e "$dev/address" && continue
+test "$(cat $dev/address)" = "00:00:00:00:00:00" && continue
+test "$(cat $dev/type)" != "$ARPHRD_ETHER" && continue
+basename "$dev"
+break
+done
+}
+
+dev="$(get_dev)"
+# prerequisite test - do we have a suitable device?
+test -n "$dev"
+
#cleanup
function cleanup {
if test -f .ncatPid
@@ -35,7 +55,7 @@
}
trap cleanup EXIT
-# prerequisite test 0: vip should not yet be registered
+# prerequisite test: vip should not yet be registered
! ip address show dev $dev | grep $vip
# run etcd with podman/docker maybe?
Bug#993557: ITP: gnome-shell-extension-pop-shell -- keyboard-driven layer for GNOME with tiling window management
Package: wnpp Severity: wishlist Owner: Dan Bungert X-Debbugs-Cc: debian-de...@lists.debian.org, danielbung...@gmail.com * Package name: gnome-shell-extension-pop-shell Version : 1.2.0 Upstream Author : System76 * URL : https://github.com/pop-os/shell * License : GPLv3 Programming Lang: JavaScript, Rust Description : keyboard-driven layer for GNOME with tiling window management Pop Shell is a keyboard-driven layer for GNOME Shell which allows for quick and sensible navigation and management of windows. The core feature of Pop Shell is the addition of advanced tiling window management.
Bug#895201: trousers uninstallable / postinst relaxing / fixes
One note on the suggested fix from Florian: I don't think we can use shopt with bare /bin/sh, so the suggested change to the init script will also fail with an error. I ended up using: if [ "$(echo /dev/tpm*)" != "/dev/tpm*" ] which is good enough for my usage but I have not tested it further. -Dan
Bug#989477: dh-golang: autopkgtest failure in package using dh-golang: copy/symlink conflict
Package: dh-golang Version: 1.51 Severity: normal Greetings! I was investigating autopkgtest failures for golang-yaml.v2 in Ubuntu, and found what I believe is a bug in dh-golang. I can reproduce equivalent failures on sid/bullseye as well. dh-golang attempts to use cp -a to populate a directory with go source code, but that directory is already partially populated with some symlinks, and cp -a doesn't like that. This fails the autopkgtest. adt log snippet: cp -a /usr/share/gocode/src "obj-x86_64-linux-gnu" cp: '/usr/share/gocode/src/gopkg.in/check.v1' and 'obj-x86_64-linux-gnu/src/gopkg.in/check.v1' are the same file cp: '/usr/share/gocode/src/github.com' and 'obj-x86_64-linux-gnu/src/github.com' are the same file cp: '/usr/share/gocode/src/launchpad.net' and 'obj-x86_64-linux-gnu/src/launchpad.net' are the same file Steps to reproduce: autopkgtest-build-lxd images:debian/sid autopkgtest golang-yaml.v2_2.4.0-1.dsc -- lxd autopkgtest/debian/sid/amd64 Note that this slightly different test passes! autopkgtest golang-yaml.v2 -- lxd autopkgtest/debian/sid/amd64 I assume this isn't golang-yaml.v2 specific, but have not proven that. I've got a suggested fix, using find to locate the symlinks and remove them before "cp -a". Please see my merge proposal, which adds a find invocation to remove symlinks. https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/17 Thanks. -Dan -- System Information: Debian Release: bullseye/sid APT prefers hirsute-updates APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500, 'hirsute-proposed'), (500, 'hirsute') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.11.0-18-generic (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-golang depends on: ii debhelper 13.3.4ubuntu1 ii libdpkg-perl 1.20.9ubuntu1 ii perl 5.32.1-3ubuntu2 dh-golang recommends no packages. dh-golang suggests no packages. -- no debconf information
Bug#977805: ntopng: FTBFS in sid
tags 977805 + security buster sid thanks There is a security angle to this FTBFS. Because ntopng is currently unable to build against ndpi 3.4, it still links against ndpi 3.0, a known vulnerable version, and users of ntopng are thus getting this vulnerable ndpi 3.0 library. ndpi (3.4-1) unstable; urgency=medium [...] * New upstream version 3.4 (Closes: #972050) - CVE-2020-11939 CVE-2020-11940 CVE-2020-15471 - CVE-2020-15472 CVE-2020-15473 CVE-2020-15474 - CVE-2020-15475 CVE-2020-15476 -Dan
Bug#986844: ranger: ftbfs - autopkgtest flakiness
Package: ranger Version: 1.9.3-3 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu hirsute ubuntu-patch ftbfs Dear Maintainer, ranger can ftbfs due to autopkgtest failure. https://tests.reproducible-builds.org/debian/history/armhf/ranger.html https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/armhf/r/ranger/20210407_151703_4b750@/log.gz https://autopkgtest.ubuntu.com/packages/r/ranger/ I believe this to be due to the "sleep 1" sometimes being insufficient to allow for program startup and execution of the target command. I propose the following: diff -Nru ranger-1.9.3/debian/tests/t/command.t ranger-1.9.3/debian/tests/t/command.t --- ranger-1.9.3/debian/tests/t/command.t 2020-01-02 19:50:07.0 -0700 +++ ranger-1.9.3/debian/tests/t/command.t 2021-04-08 15:25:53.0 -0600 @@ -5,7 +5,13 @@ . `dirname $0`/boilerplate.sh screen -D -m -T linux -- ranger --cmd "touch $TESTNAME" & -sleep 1 + +i=0 +while [ ! -f $TESTNAME ] ; do + i=$((i + 1)) + [ "$i" -ge "60" ] && break + sleep 1 +done pgrep -f $TESTNAME check_exit_code_true Session found -Dan
