Bug#1075443: rep-gtk uploaded to DELAYED=10
Thank you for your time. You may upload the package to the no delay queue, I will check it when I have free time. On September 10, 2024 11:00:47 AM GMT+01:00, Andreas Tille wrote: >Control: tags -1 pending >Thanks > >Hi Jose, > >your package rep-gtk was showing up in the list of candidates for the >Bug of the Day[1]. I've found the package in Debian team space with >other contributions (Janitor, Helmut Grohne for cross building). Thus I >took the freedom to do some "Team upload" fixing these bugs, fixing the >FTBFS bug and doing some other modernisations that go beyond a simple >NMU. Formally I might probably should have followed the Package Salvage >procedure and file an ITS bug. The fact that there was an RC bug and >the package was in collaborative maintenance space made me believe it is >sensible to simply use DELAYED=10 queue. In case you are not happy >about this just let me know and I'll remove the upload from the >deferred queue. > >Thank you for maintaining rep-gtk > Andreas. > >[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks > >-- >https://fam-tille.de
Bug#1075263: Patch for MCPP GCC14 FTBFS
Hi all,
I have attached a patch for the MCPP FTBFS reported in #1075263 can
somebody upload the patch to debian?
Cheers,
José
--
José Gutiérrez de la Concha
ZeroC, Inc.
--- a/src/expand.c
+++ b/src/expand.c
@@ -710,7 +710,9 @@
} else {
m_inf->locs.start_col = m_inf->locs.start_line = 0L;
}
-m_inf->args = m_inf->loc_args = NULL; /* Default args */
+/* Default args */
+m_inf->args = NULL;
+m_inf->loc_args = NULL;
for (num = 1, recurs = 0; num < m_num; num++)
if (mac_inf[ num].defp == defp)
recurs++; /* Recursively nested macro */
--- a/src/configed.H
+++ b/src/configed.H
@@ -299,7 +299,7 @@
#define _POSIX_ 1
#define _POSIX_SOURCE 1
#ifndef _POSIX_C_SOURCE
-#define _POSIX_C_SOURCE 1
+#define _POSIX_C_SOURCE 200112L // Ensure readlink is available
#define _POSIX_C_SOURCE_defined 1
#endif
#include"limits.h"
Bug#1076730: dart: autopkgtest regression with CMake 3.30+
The bug should be gone in the new version available on experimental that should transition together with urdfdom in the upcoming days. The boost support was removed from DART in the new version. Thanks!
Bug#1074506: libsuitesparse-dev: Can't find: libspexpython.so.3
Package: libsuitesparse-dev Version: 1:7.7.0+dfsg-2 Severity: normal X-Debbugs-Cc: jose.antonio...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (800, 'testing'), (600, 'unstable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.7-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 libsuitesparse-dev depends on: ii libamd3 1:7.7.0+dfsg-2 ii libatlas-base-dev [liblapack.so]3.10.3-14 ii libblas-dev [libblas.so]3.12.0-3 ii libbtf2 1:7.7.0+dfsg-2 ii libcamd31:7.7.0+dfsg-2 ii libccolamd3 1:7.7.0+dfsg-2 ii libcholmod5 1:7.7.0+dfsg-2 ii libcolamd3 1:7.7.0+dfsg-2 ii libcxsparse41:7.7.0+dfsg-2 ii libklu2 1:7.7.0+dfsg-2 ii liblapack-dev [liblapack.so]3.12.0-3 ii libldl3 1:7.7.0+dfsg-2 ii libopenblas-pthread-dev [liblapack.so] 0.3.27+ds-2 ii libparu01:7.7.0+dfsg-2 ii librbio41:7.7.0+dfsg-2 ii libspex31:7.7.0+dfsg-2 ii libspqr41:7.7.0+dfsg-2 ii libsuitesparse-mongoose31:7.7.0+dfsg-2 ii libsuitesparseconfig7 1:7.7.0+dfsg-2 ii libumfpack6 1:7.7.0+dfsg-2 Versions of packages libsuitesparse-dev recommends: ii libgraphblas-dev 7.4.0+dfsg-1+b1 libsuitesparse-dev suggests no packages. -- no debconf information
Bug#1071405: gnome-calculator: Can't start on Gnome-46 Wayland: core dumped
Package: gnome-calculator Version: 1:46.0-1 Severity: important X-Debbugs-Cc: jose.antonio...@gmail.com Dear Maintainer, * What led up to the situation? I've update Debian. * What exactly did you do (or not do) that was effective (or ineffective)? Type gnome-calculator in gnome-terminal. * What was the outcome of this action? "core" * What outcome did you expect instead? Start graphical user interface. --- Sorry I can't attach core file, it's 256 MiB. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (800, 'testing'), (600, 'unstable'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.9-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-calculator depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii libadwaita-1-0 1.5.0-1 ii libc62.38-11 ii libglib2.0-0t64 2.80.2-1 ii libgtk-4-1 4.12.5+ds-6+b1 ii libgtksourceview-5-0 5.12.0-1 ii libmpc3 1.3.1-1+b2 ii libmpfr6 4.2.1-1+b1 ii libsoup-3.0-03.4.4-5+b1 ii libxml2 2.9.14+dfsg-1.3+b3 Versions of packages gnome-calculator recommends: ii gvfs 1.54.0-4 ii yelp 42.2-1+b2 gnome-calculator suggests no packages. -- no debconf information
Bug#1069783: packeth: Man page refers to an non existing file
Package: packeth Version: 2.1-0.2 Severity: minor X-Debbugs-Cc: josel.seg...@gmx.es Dear Maintainer, When reading the man page for current packeth, it refers to file /usr/share/doc/packeth/README. The file doesn't exist in current package version. -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 packeth depends on: ii libc6 2.37-18 packeth recommends no packages. packeth suggests no packages. -- no debconf information
Bug#1069152: RM: xorp -- RoQA; FTBFS since 2019, not part of bullseye, bookworm or trixie, popcon 2
I agree. On April 17, 2024 8:00:48 AM GMT+01:00, Helmut Grohne wrote: >Package: ftp.debian.org >Severity: normal >Tags: ftbfs >X-Debbugs-Cc: x...@packages.debian.org, Jose M Calhariz , >Javier Fernandez-Sanguino Pen~a , Mattia Rizzolo > >Control: affects -1 + src:xorp >User: ftp.debian@packages.debian.org >Usertags: remove > >Hi, > >I request removing xorp from unstable for the following reasons: > * FTBFS since 2019 > * No maintainer upload since 2016 > * Not part of bullseye, bookworm or trixie > * Low popcon (2) > * No reverse dependencies > * Requires changes for the /usr-move transition > >Helmut
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
O 25/03/24 ás 19:17, Julian Gilbey escribiu: Hi all, Hi :) [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian If possible, I would like to contribute. At work we use the Go and Python implementations, also, in the short term, we will start using the Rust one. Just to point out, the Rust version has its own native implementation, here: https://github.com/apache/arrow-rs . Cheers, Jose -- José Manuel Abuín Mosquera PhD. | Scientific Software Developer | Researcher http://jmabuin.github.io
Bug#1067237: ngircd: missing ssl security patch in debian's ngircd package
Source: ngircd
Version: 26.1-1
Severity: important
Tags: patch
Dear Maintainer,
The master branch of the upstream ngircd changelog informs about an
SSL security related patch [1] that is missing in the -26-1 ngircd debian
package patches.
Here's the Changelog entry:
[[
Respect "SSLConnect" option for incoming connections and do not accept
incoming plain-text ("non SSL") server connections for servers configured
with "SSLConnect" enabled. This change prevents an authenticated
client-server being able to force the server-server to send its password
on a plain-text connection when SSL/TLS was intended.
]]
It may be interesting to cherry-pick the patch that fixes this issue [2].
I added it by hand and didn't detect any issue compiling or running
ngircd.
[1]
https://github.com/ngircd/ngircd/blob/c1c0bca0e2fa7b678a18155abaf364fcb9dab427/ChangeLog#L53
[2]
https://github.com/ngircd/ngircd/commit/21c1751b045b0be49e584a4ba191a330e0c381bb
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Browsing the changelog on the github repository for the ngircd server.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I cherry-picked and added the upstream patch from github [2] to the
debian package source obtained thru apt-get source, then compiled and
installed the package.
* What was the outcome of this action?
Although I cannot run the test scenario, this patches the SSL issue
reported by the code developer, avoid tricking the server to send
its password on the clear in server-server connections..
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#965945:
I've prepared the 1.5 update in a merge-request and can maintain the package. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061300 (needs sponsoring)
Bug#1061300: lcm: Update to version 1.5.0
Thanks Vagrant for the reply and the information. Updating the info about the 1.5 update, the merge-request is ready to review and sponsored: - https://salsa.debian.org/debian/lcm/-/merge_requests/1 On Mon, Jan 22, 2024 at 8:29 PM Vagrant Cascadian wrote: > On 2024-01-22, Jose Luis Rivero wrote: > > lcm upstream released the version 1.5.0 on April 2023. It would be great > to > > have it packaged and available on Debian Sid. > > > > I canhelp with code changes if the maintainer or the team are willing to > > sponsor and review them. > > Well the "team" is the Debian QA Group, which effectively means it needs > an actual maintainer: > > https://bugs.debian.org/965945 > > On the positive side, any Debian Developer can make changes to the > package, so your pool of potential sponsors is quite large! > > If you want to prepare an upload for someone to sponsor, this has some > helpful information and infrastructure: > > https://mentors.debian.net/ > > live well, > vagrant >
Bug#1061300: lcm: Update to version 1.5.0
Source: lcm Version: 1.3.1+repack1-7 Severity: wishlist Dear Maintainer, lcm upstream released the version 1.5.0 on April 2023. It would be great to have it packaged and available on Debian Sid. I canhelp with code changes if the maintainer or the team are willing to sponsor and review them. Thanks.
Bug#1054012: at: defer placement of systemd unit to systemd's pkgconf file
Hi, Can anyone do a NMU? I have no success in finding free time to work on this and I do not want to delay more this fix. Kind regards Jose M Calhariz On 12/8/23 21:22, Chris Hofstaedtler wrote: Hi at Maintainers, Hi Jose, Ansgar, On Sun, Oct 15, 2023 at 11:15:44AM +0200, Helmut Grohne wrote: We want to move files from aliased directories to /usr (see DEP17). The at package is involved, because it ships a systemd unit in /lib. I propose that instead of hard coding this directory, you may defer the placement to systemd's pkgconf file. The advantage of doing so is that a backport of apt to an older release will automatically revert back to /lib and thus honour the file move moratorium that still applies to bookworm. I'm attaching a patch for your convenience. Is there anything we can do to help you out and get Helmut's patch applied? Thanks for considering, Chris
Bug#1055253: amanda: diff for NMU version 1:3.5.1-11.1
Thank you for your work. No need for the delay. Kind regards. Jose M Calhariz On December 3, 2023 1:14:09 PM GMT+00:00, Tobias Frost wrote: >Control: tags 1055253 + patch >Control: tags 1055253 + pending > >Dear maintainer, > >I've prepared an NMU for amanda (versioned as 1:3.5.1-11.1) and >uploaded it to DELAYED/5. Please feel free to tell me if I >should delay it longer. > >Regards. >
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Hi On Tue, Nov 07, 2023 at 08:33:58PM +0100, Diederik de Haas wrote: > Control: found -1 6.1~rc3-1~exp1 > Control: found -1 6.1.55-1 > > On Saturday, 4 November 2023 20:35:43 CET Jose M Calhariz wrote: > > > Ok. Please test (when you have time) 6.1.55-1. > > > > Fail : Linux afs31 6.1.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian > > 6.1~rc3-1~exp1 (2022-11-02) x86_64 GNU/Linux > > > > Fail : Linux afs31 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 > > (2023-09-29) x86_64 GNU/Linux > > > > Done. I tested even the first 6.1 on Debian. Both of them failed. > > Thanks, updated metadata accordingly. > So now we know it's indeed present in the whole 6.1 series. > > > > Unfortunately there isn't a 6.2 kernel uploaded to the Debian archive and > > > thus not available on snapshot.d.o, but testing 6.3.1-1~exp1 should be > > > useful. > > Please test with with 6.3.1-1~exp1 to make sure it was fixed then (too). > > Unfortunately, the commit list between 6.1 and 6.3.1 is quite large: > me@pc:~/dev/kernel.org/linux$ git log --oneline v6.1..v6.3.1 -- fs/xfs | wc -l > 159 > > If that list was small, I could've suggested to try 'backporting' a couple of > patches, but that avenue seems rather pointless in this case. > > It's probably also useful to verify whether it's also present in the whole > 5.10 series, which should give (even) more data points. > > I think the next step should be to 'forward' this bug report to the upstream > mailing list at linux-...@vger.kernel.org I do not follow closely linux-xfs mailing list, but I think other people already reported problems with 6.1 and are trying to do the effort of delimiting the patch and test a backport to 6.1. Kind regards Jose M Calhariz -- -- Egoista, s. m. Um sujeito mais interessado em si próprio que em mim. -- Ambrose Bierce signature.asc Description: PGP signature
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Hi On Thu, Nov 02, 2023 at 07:40:38PM +0100, Diederik de Haas wrote: > > On Thursday, 2 November 2023 18:03:25 CET Jose M Calhariz wrote: > > On Thu, Nov 02, 2023 at 03:37:39PM +0100, Diederik de Haas wrote: > > > On Wednesday, 5 July 2023 19:07:15 CET Jose M Calhariz wrote: > > > > Package: src:linux > > > > Version: 6.1.27-1 > > > > > > Can you try with the latest version in the 6.1.x series to see if the > > > problem is still there? > > > > As I need to setup ASAP the servers in production I do not know if I > > have time in the next days. It works with backports kernels. > > No problem. > > > The latest kernels I tested were: > > Fail : Linux afs31 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.37-1 > > (2023-07-03) x86_64 GNU/Linux > > Ok. Please test (when you have time) 6.1.55-1. Fail : Linux afs31 6.1.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1~rc3-1~exp1 (2022-11-02) x86_64 GNU/Linux Fail : Linux afs31 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux Done. I tested even the first 6.1 on Debian. Both of them failed. > Also verify if it's also present in 6.1~rc3-1~exp1 to make sure it's present > in the whole 6.1 series. > Use https://snapshot.debian.org/binary/linux-image-amd64/ to get it/them. > > If the bug is NOT present in either the latest or the first, then try other > versions till you find the last one that work and the first one that fails. > > > OK : Linux afs31 6.4.0-0.deb12.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian > > 6.4.4-3~bpo12+1 (2023-08-08) x86_64 GNU/Linux > > It was fixed in 6.3.7-1, so it was expected that a later versions also works. > But let's ignore bpo as it likely won't provide useful data points. > > Unfortunately there isn't a 6.2 kernel uploaded to the Debian archive and > thus > not available on snapshot.d.o, but testing 6.3.1-1~exp1 should be useful. > > > The bug is present on Debian v11 too. So is an old bug with fixes on > > kernel 6.2 rc something. > > I'd recommend to focus first on the 6.1 series for now. > If at a later point testing with 5.10 may be useful, we can do that then. Kind regards Jose M Calhariz -- -- A vida feliz, meu Deus, consiste em nos alegrarmos em vos, de vos e por vos signature.asc Description: PGP signature
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
On Thu, Nov 02, 2023 at 03:37:39PM +0100, Diederik de Haas wrote: > Control: tag -1 moreinfo > > On Wednesday, 5 July 2023 19:07:15 CET Jose M Calhariz wrote: > > Package: src:linux > > Version: 6.1.27-1 > > Can you try with the latest version in the 6.1.x series to see if the problem > is still there? As I need to setup ASAP the servers in production I do not know if I have time in the next days. It works with backports kernels. The latest kernels I tested were: Fail : Linux afs31 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.37-1 (2023-07-03) x86_64 GNU/Linux OK : Linux afs31 6.4.0-0.deb12.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-3~bpo12+1 (2023-08-08) x86_64 GNU/Linux > > > On this hardware I am chasing a data corruption for several months on > > Debian V11 and Debian v12. Now that I was pointed that linux kernel > > had some problems with XFS solved in later 6.3 kernel I can reproduce > > the problem. > > > > It seams the problem went away with current Debian testing kernel: > > > > ii linux-image-6.3.0-1-amd646.3.7-1 amd64Linux 6.3 > > for 64-bit PCs (signed) > > > > Is there anyone willing to backport the XFS fixes into > > linux-image-6.1.0 and linux-image-5.10.0? > > If the problem is still present in the latest 6.1 kernel, then you need to > find > out which patch(es) actually fix the problem. > The easiest way to start with that is to find the last kernel which exhibits > the issue and then the first one where it is fixed. > https://snapshot.debian.org/binary/linux-image-amd64/ should help > with that. The bug is present on Debian v11 too. So is an old bug with fixes on kernel 6.2 rc something. > > When the range has been narrowed, a `git bisect` should identify the specific > commit(s) which fixes the issue. > https://wiki.debian.org/DebianKernel/GitBisect should help with that > > When that/those have been identified, it should be reported to the upstream > kernel so that they can incorporate those fixes in their LTS kernel(s) which > Debian then will pick up automatically. > > HTH -- -- A vida feliz, meu Deus, consiste em nos alegrarmos em vos, de vos e por vos signature.asc Description: PGP signature
Bug#1032391: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Hi, After some research it was found the problem was not HW related, but related with XFS driver and is present until linux 6.1. So I opened new bug report on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040416 Kind regards Jose M Calhariz -- -- A vida feliz, meu Deus, consiste em nos alegrarmos em vos, de vos e por vos signature.asc Description: PGP signature
Bug#1052238: [pkg-php-pear] Bug#1052238: php-net-smtp: Please, consider this email address
I'm sorry,
My code and the example from
https://pear.php.net/manual/en/package.mail.mail-mime.example.php, both
use the statement:
$mail =Mail::factory('mail');
this statement forced the use of the mail driver based on the php
intrinsic function mail() and is this function the one who has the bug I
reported.
Changing this statement to:
$mail =Mail::factory('smtp');
the smtp driver based on php-net-smtp is used and its behavior is correct.
Conclusion: the php-net-smtp package works fine and the bug might be closed.
Thansk very much for your attention and I regret the inconveniences.
On 21/9/23 14:57, Guilhem Moulin wrote:
On Thu, 21 Sep 2023 at 13:58:18 +0200, J.L. Fernandez Jambrina wrote:
Unfortunatelly I don't know how to use setDebug() to see what's is
being passed to send()
Please see https://github.com/pear/Net_SMTP#debugging to debug Net_SMTP.
but I used two calls to var_dump() to see it:
AFAICT this show what's being passed to Mail_Mime or Mail, not Net_SMTP.
Net_SMTP treats data as as opaque string containing both the header and
body parts, just like the SMTP protocol itself.
Bug#890383: ignition-common FTBFS on big endian: UNIT_Util_TEST (Failed)
Resolved long ago. On Wed, Apr 11, 2018 at 6:31 PM Jose Luis Rivero wrote: > Thanks for the report. I've submitted the bug upstream: > https://bitbucket.org/ignitionrobotics/ign-common/issues/33/sha-test-in-big-endian-machines > > On Wed, Feb 14, 2018 at 10:46 AM, Adrian Bunk wrote: > >> Source: ignition-common >> Version: 1.0.1-1 >> Severity: important >> >> https://buildd.debian.org/status/package.php?p=ignition-common&suite=sid >> >> ... >> >> 98% tests passed, 1 tests failed out of 59 >> >> Total Test time (real) = 10.32 sec >> >> The following tests FAILED: >> 49 - UNIT_Util_TEST (Failed) >> Errors while running CTest >> Makefile:143: recipe for target 'test' failed >> make[2]: *** [test] Error 8 >> >> -- >> debian-science-maintainers mailing list >> debian-science-maintain...@lists.alioth.debian.org >> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers >> > >
Bug#890383: ignition-common FTBFS on big endian: UNIT_Util_TEST (Failed)
The bug was fixed some years ago. Closing. On Wed, Apr 11, 2018 at 6:31 PM Jose Luis Rivero wrote: > Thanks for the report. I've submitted the bug upstream: > https://bitbucket.org/ignitionrobotics/ign-common/issues/33/sha-test-in-big-endian-machines > > On Wed, Feb 14, 2018 at 10:46 AM, Adrian Bunk wrote: > >> Source: ignition-common >> Version: 1.0.1-1 >> Severity: important >> >> https://buildd.debian.org/status/package.php?p=ignition-common&suite=sid >> >> ... >> >> 98% tests passed, 1 tests failed out of 59 >> >> Total Test time (real) = 10.32 sec >> >> The following tests FAILED: >> 49 - UNIT_Util_TEST (Failed) >> Errors while running CTest >> Makefile:143: recipe for target 'test' failed >> make[2]: *** [test] Error 8 >> >> -- >> debian-science-maintainers mailing list >> debian-science-maintain...@lists.alioth.debian.org >> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers >> > >
Bug#1041165:
Thanks for finding and reporting! It's now fixed upstream in [1]. I'll release a patch for the Debian package. Cheers, JL [1] https://github.com/MRPT/mrpt/commit/b44576953cf94781c3256cd1077ba500fa1d89de -- ___ Jose Luis Blanco-Claraco CITE-IV 1.05 Universidad de Almería, Departamento de Ingeniería 04120 Almería (Spain) http://www.ual.es/~jlblanco/ ___
Bug#1034348: at: autopkgtest regression on arm64
Hi, I believe my last update fixed the problem can someone double check?
Kind regards
Jose M Calhariz
On July 7, 2023 11:26:22 AM GMT+01:00, Jose M Calhariz
wrote:
>I too think it's a race condition. I made some changes to the test but the
>upload to Debian did not went well.
>
>
>On July 6, 2023 2:12:59 PM GMT+01:00, Vincent Lefevre
>wrote:
>>On 2023-07-05 18:58:13 +0200, Johannes Christ wrote:
>>> Is there another way to reproduce this issue?
>>
>>I'm wondering whether there is a race condition in the test:
>>
>># use at command to schedule a job.
>>echo "echo `date` > ${WORKDIR}/${TMPFILE}" | at now + 1 minute
>>
>>So the file is expected to be created 1 minute later.
>>
>>Then in the script:
>>
>>sleep 2
>>
>>[...]
>>
>>sleep 58
>>
>>if grep -Fq "UTC" $WORKDIR/$TMPFILE
>>
>>[...]
>>
>>So the script waits for 1 minute (and some other fast commands)
>>before checking the existence of the file, which is the wait time
>>given to "at".
>>
>>I can see 2 possible issues:
>>
>>1. The system is a bit slow, and the job execution will take a bit
>>more time.
>>
>>2. Time inaccuracies. What are the guaranties given by the system?
>>
>>--
>>Vincent Lefèvre - Web: <https://www.vinc17.net/>
>>100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>>Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1000101: eterm: depends on obsolete pcre3 library
Bastian Germann wrote: > Hi, > > I am uploading a NMU to fix this. The debdiff is attached. > > Sincerely, > Bastian Thank you so much for fixing this. I am planing to review build dependences to removed those no needed. Sincerely, Jose
Bug#1034348: at: autopkgtest regression on arm64
I too think it's a race condition. I made some changes to the test but the
upload to Debian did not went well.
On July 6, 2023 2:12:59 PM GMT+01:00, Vincent Lefevre
wrote:
>On 2023-07-05 18:58:13 +0200, Johannes Christ wrote:
>> Is there another way to reproduce this issue?
>
>I'm wondering whether there is a race condition in the test:
>
># use at command to schedule a job.
>echo "echo `date` > ${WORKDIR}/${TMPFILE}" | at now + 1 minute
>
>So the file is expected to be created 1 minute later.
>
>Then in the script:
>
>sleep 2
>
>[...]
>
>sleep 58
>
>if grep -Fq "UTC" $WORKDIR/$TMPFILE
>
>[...]
>
>So the script waits for 1 minute (and some other fast commands)
>before checking the existence of the file, which is the wait time
>given to "at".
>
>I can see 2 possible issues:
>
>1. The system is a bit slow, and the job execution will take a bit
>more time.
>
>2. Time inaccuracies. What are the guaranties given by the system?
>
>--
>Vincent Lefèvre - Web:
Bug#1038435: libmariadb-java: Request to upgrade
Package: libmariadb-java Version: 2.7.6-1 Severity: normal Dear Maintainer, Please consider upgrading the MariaDB Java connector to the 3.0 series in bookworm. For OpenJDK 17 (the default JVM in bookworm) the 3.0 series is the recommended version: * https://mariadb.com/kb/en/about-mariadb-connector-j/#java-compatibility Best regards, José Gonçalves -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libmariadb-java depends on no packages. libmariadb-java recommends no packages. Versions of packages libmariadb-java suggests: pn libjna-java pn libjna-platform-java pn libslf4j-java -- no debconf information
Bug#1038204: tomcat10 complains about old Apache Tomcat Native library
Package: tomcat10 Version: 10.1.6-1 Severity: normal Dear Maintainer, After installing tomcat10 in bookworm I see the following log message when I start the service: INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent An older version [1.2.35] of the Apache Tomcat Native library is installed, while Tomcat recommends a minimum version of [2.0.1] Please consider upgrading the libtcnative-1 package as recommended by the Tomcat developers. Best regards, José Gonçalves -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tomcat10 depends on: ii lsb-base11.6 ii systemd [systemd-tmpfiles] 252.6-1 ii sysvinit-utils [lsb-base] 3.06-4 ii tomcat10-common 10.1.6-1 ii ucf 3.0043+nmu1 Versions of packages tomcat10 recommends: ii libtcnative-1 1.2.35-1 Versions of packages tomcat10 suggests: ii tomcat10-admin 10.1.6-1 ii tomcat10-docs 10.1.6-1 pn tomcat10-examples pn tomcat10-user -- no debconf information
Bug#237675: possible interest
I have a brief project that will be of interest to you. Reach me back via email (azzopa...@sonic.net) to know more details. AVISO LEGAL: - Las opiniones expresadas en el presente mensaje no representan necesariamente la opinión oficial de La Universidad de La Salle. - Este mensaje es confidencial, puede contener información privilegiada y no puede ser usado ni divulgado por personas distintas de su destinatario. Si obtiene esta transmisión por error, por favor destruya su contenido y avise al remitente. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. - Este mensaje ha sido sometido a programas antivirus. No obstante, La Universidad de La Salle no asume ninguna responsabilidad por eventuales daños generados por el recibo y uso de este material, siendo responsabilidad del destinatario verificar con sus propios medios de la existencia de virus u otros defectos. LEGAL WARNING: - The opinions stated in the present message do not necessarily represent the official opinion of Universidad de La Salle. - This message is confidential and may contain privileged information, it cannot be used or disclosed by any person other than the individual to whom it is addressed. If obtained by error, please destroy the information received and contact the sender. Its retention, recording, use or distribution with any intention are prohibited. - This message has been tested by antivirus software. Nonetheless, the Universidad de La Salle assumes no responsibility for damages caused by the receptor or use of the material, given that it is the responsibility of the addressee to verify by his own means the presence of a virus or any other harmful defect. '.
Bug#1033882: kde-plasma-desktop: Fail to start plasma-kded.service
Package: kde-plasma-desktop Version: 5:142 Severity: important X-Debbugs-Cc: j...@zeroc.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** With a fresh install of debian 12, KDE login fails all the time, looking throw the logs I see Apr 03 14:19:18 debian systemd[1229]: Starting plasma-kded.service - KDE Daemon... Apr 03 14:19:18 debian kded5[1477]: qt.qpa.xcb: could not connect to display Apr 03 14:19:18 debian kded5[1477]: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. Apr 03 14:19:18 debian kded5[1477]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Apr 03 14:19:18 debian kded5[1477]: Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xc> Apr 03 14:19:18 debian systemd[1]: Started systemd-coredump@25-1478-0.service - Process Core Dump (PID 1478/UID 0). Apr 03 14:19:18 debian systemd-coredump[1479]: [🡕] Process 1477 (kded5) of user 0 dumped core. Module libsystemd.so.0 from deb systemd-252.6-1.amd64 Module libudev.so.1 from deb systemd-252.6-1.amd64 Stack trace of thread 1477: #0 0x7f8a1f4a9ccc n/a (libc.so.6 + 0x8accc) #1 0x7f8a1f45aef2 raise (libc.so.6 + 0x3bef2) #2 0x7f8a1f445472 abort (libc.so.6 + 0x26472) #3 0x7f8a1f690c79 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5 + 0x90c79) #4 0x7f8a1fd34503 _ZN22QGuiApplicationPrivate25createPlatformIntegrationEv (libQt5Gui.so.5 + 0x134503) #5 0x7f8a1fd349b0 _ZN22QGuiApplicationPrivate21createEventDispatcherEv (libQt5Gui.so.5 + 0x1349b0) #6 0x7f8a1f8b7f15 _ZN23QCoreApplicationPrivate4initEv (libQt5Core.so.5 + 0x2b7f15) #7 0x7f8a1fd3786c _ZN22QGuiApplicationPrivate4initEv (libQt5Gui.so.5 + 0x13786c) #8 0x7f8a20768519 _ZN19QApplicationPrivate4initEv (libQt5Widgets.so.5 + 0x168519) #9 0x556b56b5b473 n/a (kded5 + 0x7473) #10 0x7f8a1f44618a n/a (libc.so.6 + 0x2718a) #11 0x7f8a1f446245 __libc_start_main (libc.so.6 + 0x27245) #12 0x556b56b5b5c1 n/a (kded5 + 0x75c1) ELF object binary architecture: AMD x86-64 *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kde-plasma-desktop depends on: ii kde-baseapps 4:22.12.3+5.142 ii plasma-desktop4:5.27.2-1 ii plasma-workspace 4:5.27.2-1 ii udisks2 2.9.4-4 ii upower0.99.20-2 Versions of packages kde-plasma-desktop recommends: ii kwin-x11 4:5.27.2-1 ii sddm 0.19.0-5 ii xserver-xorg 1:7.7+23 Versions of packages kde-plasma-desktop suggests: ii kdeconnect 22.12.3-1 -- no debconf information
Bug#1033292: Subject:Re: Bug#1033292: unblock: amanda/1:3.5.1-11
Hi,
I have updated the git repository on salsa abount amanda and created a
signed tag. g...@salsa.debian.org:debian/amanda.git
As the debdiff amanda_3.5.1-10_source.changes
amanda_3.5.1-11_source.changes did not work as I expected I am
doing a git diff:
diff --git a/debian/changelog b/debian/changelog
index d4e1821..498f6f9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+amanda (1:3.5.1-11) unstable; urgency=medium
+
+ * d/p/49-fix-CVE-2022-37705_part_2: 48-fix-CVE-2022-37705 broken one use
+case at least, this patch fix it, fixing the following two bugs.
+ * Bug fix: "backups fail with the following summary "FAILED [no
+backup size line]"", thanks to Norman Lyon (Closes: #1032330).
+ * Bug fix: "Amanda is unusable", thanks to Kamil Jonca (Closes:
+#1032884).
+
+ -- Jose M Calhariz Tue, 21 Mar 2023 17:35:47 +
+
amanda (1:3.5.1-10) unstable; urgency=medium
* d/p/48-fix-CVE-2022-37705: Fix CVE-2022-37705.
diff --git a/debian/patches/49-fix-CVE-2022-37705_part_2
b/debian/patches/49-fix-CVE-2022-37705_part_2
new file mode 100644
index 000..74341a6
--- /dev/null
+++ b/debian/patches/49-fix-CVE-2022-37705_part_2
@@ -0,0 +1,24 @@
+Description: Fix the fix for CVE-2022-37705
+Author: pcahyna https://github.com/pcahyna
+
+Index: amanda.git/client-src/runtar.c
+===
+--- amanda.git.orig/client-src/runtar.c2023-03-05 00:10:46.916884175
+
amanda.git/client-src/runtar.c 2023-03-05 00:15:52.189417756 +
+@@ -191,9 +191,13 @@ main(
+ g_str_has_prefix(argv[i],"--newer") ||
+ g_str_has_prefix(argv[i],"--exclude-from") ||
+ g_str_has_prefix(argv[i],"--files-from")) {
+- good_option++;
+- } else if (argv[i][0] != '-') {
+- /* argument values are accounted for here */
++ if (strchr(argv[i], '=')) {
++ good_option++;
++ } else {
++ /* Accept theses options with the following argument */
++ good_option += 2;
++ }
++} else if (argv[i][0] != '-') {
+ good_option++;
+ }
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 92dde9d..2be2df4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -45,6 +45,7 @@ reproducible-build
##
# Patches to fix CVEs from 2022
48-fix-CVE-2022-37705
+49-fix-CVE-2022-37705_part_2
50-fix-CVE-2022-37704
52-fix-CVE-2022-37704_part_2
56-fix-CVE-2022-37703
I have attached the two patches for CVE-2022-37705 that I use in the
package, the one with the regression and the fix.
Kind regards
Jose M Calhariz
--
--
Ha alguma coisa nos armarios que deixa os esqueletos
inquietos.
-- John Barrymore
Description: Fix CVE-2022-37705
Author: Prajwal T R https://github.com/prajwaltr93
Index: amanda.git/client-src/runtar.c
===
--- amanda.git.orig/client-src/runtar.c 2021-06-20 21:02:56.627301251 +0100
+++ amanda.git/client-src/runtar.c 2023-02-24 12:40:05.041286442 +
@@ -191,9 +191,9 @@ main(
g_str_has_prefix(argv[i],"--newer") ||
g_str_has_prefix(argv[i],"--exclude-from") ||
g_str_has_prefix(argv[i],"--files-from")) {
- /* Accept theses options with the following argument */
- good_option += 2;
+ good_option++;
} else if (argv[i][0] != '-') {
+ /* argument values are accounted for here */
good_option++;
}
}
Description: Fix the fix for CVE-2022-37705
Author: pcahyna https://github.com/pcahyna
Index: amanda.git/client-src/runtar.c
===
--- amanda.git.orig/client-src/runtar.c 2023-03-05 00:10:46.916884175 +
+++ amanda.git/client-src/runtar.c 2023-03-05 00:15:52.189417756 +
@@ -191,9 +191,13 @@ main(
g_str_has_prefix(argv[i],"--newer") ||
g_str_has_prefix(argv[i],"--exclude-from") ||
g_str_has_prefix(argv[i],"--files-from")) {
- good_option++;
- } else if (argv[i][0] != '-') {
- /* argument values are accounted for here */
+ if (strchr(argv[i], '=')) {
+ good_option++;
+ } else {
+ /* Accept theses options with the following argument */
+ good_option += 2;
+ }
+} else if (argv[i][0] != '-') {
good_option++;
}
}
signature.asc
Description: PGP signature
Bug#1033292: unblock: amanda/1:3.5.1-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ama...@packages.debian.org, jose.calha...@tecnico.ulisboa.pt,
calha...@debian.org, ns-l...@dsi.ist.utl.pt
Control: affects -1 + src:amanda
Please unblock package amanda
[ Reason ]
The previous version on the fix for CVE-CVE-2022-37705 introduced a
regression that is fixed by this version.
[ Impact ]
Breaks the use of tar, for backups in some setups, on the affected
clients, i.e., the use of package amanda-client. The server can not
backup itself, but can backups clients with good amanda client
software,
[ Tests ]
I manually tested the affected version and the fixed version, using a
VM running testing (bookworm) with a amanda compiled for sid. The
test is to do backup of the server. The detail that breaks or not is
two options in a dumptype that specifies what program to use for
backup. When using traditional and old interface for gnutar it
breaks. When using the new interface it is not affected.
I do not have experience in C language to do a proper review of the
patch that is very simple, but broken in 3.5.1-10.
[ Risks ]
The fix in 3.5.1-10 for the three CVEs are a low risks ones because
user backup is a restricted user. Only people with previliges already
can login as user backup and try to run the setgid binaries. For the
people affected by regression 3.5.1-10 can workaround using an older
version on the affected clients. This bugs does not affect other
packages as amanda-client is a leaf package.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
for name in amanda-client amanda-common amanda-server ; do debdiff
"/var/cache/apt/archives/${name}_1%3a3.5.1-10_amd64.deb"
"/root/${name}_3.5.1-11_amd64.deb" ; done
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} libxml-simple-perl,
perl:any, libc6 (>= 2.34), libglib2.0-0 (>= 2.31.8), libreadline8 (>= 6.0)
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Suggests: amanda-server (= [-1:3.5.1-10)-] {+1:3.5.1-11)+} | amanda-client (=
[-1:3.5.1-10)-] {+1:3.5.1-11)+}
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} bsd-mailx | mailx,
libjson-perl, perl:any, libc6 (>= 2.34), libcurl4 (>= 7.16.2), libglib2.0-0 (>=
2.31.8)
Installed-Size: [-1076-] {+1077+}
Suggests: amanda-client (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} cpio | mt-st,
gnuplot
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
unblock amanda/1:3.5.1-11
Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)
On 3/13/23 13:16, Kamil Jońca wrote: "Debian Bug Tracking System" writes: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1032884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884. dpkg -l "amanda*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== un amanda (no description available) ii amanda-client 1:3.5.1-9+b1 amd64Advanced Maryland Automatic Network Disk Archiver (Client) ii amanda-common 1:3.5.1-9+b1 amd64Advanced Maryland Automatic Network Disk Archiver (Libs) ii amanda-server 1:3.5.1-10 amd64Advanced Maryland Automatic Network Disk Archiver (Server) Work properly, so this is kind a regression. KJ Hi What dumptypes do you use in amanda? I am preparing one update to fix a regression and I would like to know your situation is covered by my fix. Kind regards Jose M Calhariz
Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)
On 3/15/23 18:29, Kamil Jońca wrote:
Jose M Calhariz writes:
On 3/13/23 13:16, Kamil Jońca wrote:
"Debian Bug Tracking System" writes:
Thank you for filing a new Bug report with Debian.
You can follow progress on this Bug here: 1032884:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884.
dpkg -l "amanda*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---==
un amanda (no description available)
ii amanda-client 1:3.5.1-9+b1 amd64Advanced Maryland Automatic
Network Disk Archiver (Client)
ii amanda-common 1:3.5.1-9+b1 amd64Advanced Maryland Automatic
Network Disk Archiver (Libs)
ii amanda-server 1:3.5.1-10 amd64Advanced Maryland Automatic
Network Disk Archiver (Server)
Work properly, so this is kind a regression.
KJ
Hi
What dumptypes do you use in amanda?
--8<---cut here---start->8---
define dumptype gnutar-base {
compress client custom
client-custom-compress "/usr/local/lib/amanda/xz9"
encrypt client
client-encrypt "/usr/local/lib/amanda/encgpg"
index yes
program "GNUTAR"
maxpromoteday 30
}
define dumptype gnutar-local {
gnutar-base
auth "local"
}
define dumptype gnutar-bsdtcp {
gnutar-base
auth "bsdtcp"
}
define dumptype gnutar-bsdtcp-nocomp {
gnutar-bsdtcp
compress none
}
define dumptype gnutar-local-nocomp {
gnutar-local
compress none
}
--8<---cut here---end--->8---
"/usr/local/lib/amanda/xz9" = exec /usr/bin/xz "$@"
"/usr/local/lib/amanda/encgpg" = exec gpg -e (in case of dumping)
Thank you, your problem is known and will be fixed on the next upload.
Kind regards
Jose M Calhariz
Bug#1018023: Update on this bug?
Dear Matthew, I have just uploaded to mentors a new version of the package fixing this bug. I will made other improvements after Bookworm is released as we are very close to the full freeze. The new package can be found here: https://mentors.debian.net/package/eterm/ Thank you for your interest in Eterm, Jose Matthew Vernon wrote: > Hi, > > On 14/02/2023 18:36, Jose Antonio Jimenez Madrid wrote: > >> I will test this patch and let you to know whether the bug is fixed. > > Any joy? We're approaching the time that eterm is going to be > autoremoved from bookworm... > > Thanks, > > Matthew
Bug#1032330: amanda-client: backups fail with the following summary "FAILED [no backup size line]"
Hi,
I was able to reproduce the problem on my setup. While I search for a
fix you may use another
workaround. The option ``program "GNUTAR"`` is broken but ``program
"APPLICATION" application "amgtar"``
works and you have more control still using tar.
Use man amgtar for more information.
Kind regards
Jose M Calhariz
On 3/4/23 06:17, Norman Lyon wrote:
Package: amanda-client
Version: 1:3.5.1-10
Severity: normal
Dear Maintainer,
* What led up to the situation?
upgrade of amanda-{client,common,server} from 1:3.5.1-9+b1 to 1:3.5.1-10
* What exactly did you do (or not do) that was effective (or
ineffective)?
standard backup with normal package: failed.
* What was the outcome of this action?
runtar completes in sane manner, defaulDailySet1g to stdout; sendbackup
completes; backup works
myUser@mySystem:~$ for f in sendbackup.20230303031033.debug
runtar.20230303031033.debug ; do printf
"==\n/var/log/amanda/client/DailySet1/$f\n==\n" ; sudo cat
/var/log/amanda/client/DailySet1/$f ; done
==
/var/log/amanda/client/DailySet1/sendbackup.20230303031033.debug
==
Fri Mar 03 03:10:33.465231875 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448741 ruid 34 euid 34 version 3.5.1: start at Fri Mar 3
03:10:33 2023
Fri Mar 03 03:10:33.465266461 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Version 3.5.1
Fri Mar 03 03:10:33.465782977 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448741 ruid 34 euid 34 version 3.5.1: rename at Fri Mar 3
03:10:33 2023
Fri Mar 03 03:10:33.465876561 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Parsed request as: program `GNUTAR'
Fri Mar 03 03:10:33.465885463 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: disk `/boot'
Fri Mar 03 03:10:33.465890405 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: device `/boot'
Fri Mar 03 03:10:33.465894886 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: level 1
Fri Mar 03 03:10:33.465899391 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: since NODATE
Fri Mar 03 03:10:33.465903975 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: options `'
Fri Mar 03 03:10:33.465908806 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: datapath `AMANDA'
Fri Mar 03 03:10:33.465963068 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: start: mySystem:/boot lev 1
Fri Mar 03 03:10:33.465978023 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Spawning "/bin/gzip /bin/gzip --best" in pipeline
Fri Mar 03 03:10:33.466337828 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: gnutar: pid 1448743: /bin/gzip
Fri Mar 03 03:10:33.466360045 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448743: /bin/gzip --best
Fri Mar 03 03:10:33.48981 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: doing level 1 dump as listed-incremental from
'/var/lib/amanda/gnutar-lists/mySystem_boot_0' to
'/var/lib/amanda/gnutar-lists/mySystem_boot_1.new'
Fri Mar 03 03:10:33.467301177 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Spawning "/usr/lib/amanda/runtar runtar DailySet1 /bin/tar
--create --file - --directory /boot --one-file-system --listed-incremental
/var/lib/amanda/gnutar-lists/mySystem_boot_1.new --sparse
--ignore-failed-read --totals ." in pipeline
Fri Mar 03 03:10:33.467327842 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Dupped file descriptor 3 to 11
Fri Mar 03 03:10:33.467621737 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: gnutar: /usr/lib/amanda/runtar: pid 1448747
Fri Mar 03 03:10:33.467655460 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: shm_ring_link /amanda_shm_control-1448740-0
Fri Mar 03 03:10:33.467707662 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646e000 1
Fri Mar 03 03:10:33.467726841 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646d000 1
Fri Mar 03 03:10:33.467742817 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646c000 1
Fri Mar 03 03:10:33.467765242 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646b000 1
Fri Mar 03 03:10:33.467773426 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: shm_ring_producer_set_size
Fri Mar 03 03:10:33.467871033 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Started backup
Fri Mar 03 03:10:33.467934476 2023: pid 1448741: thd-0x5643d36930c0:
sendbackup: fd_to_shm_ring
Fri Mar 03 03:10:33.467941382 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Started index creator: "/bin/tar -tf - 2>/dev/null | sed -e
's/^\.//'"
Fri Mar 03 03:10:33.483602083 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: 119: strange(?): runtar: error [runtar invalid option: -]
Fri Mar 03 03:10:33.485632813 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Index created successfully
Fri Mar
Bug#1029829: Server connections refused after applying update?
Hi Barry, Can you please open a new bug report for this problem? Kind regards Jose M Calhariz On February 23, 2023 9:40:53 PM GMT+00:00, Barry Trent wrote: >I applied this update to my one remaining buster machine and now it is >refusing to connect to my bullseye-based amanda backup server. > >amcheck and the amanda server are both reporting "Connection refused" when >accessing the updated buster machine. > >-- >Barry A. Trent >952-829-5864, x109 >barry.tr...@atcorp.com >
Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi, just to tell that I am working on CVE-2022-37705, currently checking if the fix work on my workbench. Kind regards Jose M Calhariz On February 15, 2023 11:10:25 PM GMT+00:00, Amanda Trusted wrote: >Hi Jose, > >Here are the relevant bug fixes - >[0] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37704 >https://www.cve.org/CVERecord?id=CVE-2022-37704 >Fix - https://github.com/zmanda/amanda/pull/197 > >[1] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37705 >https://www.cve.org/CVERecord?id=CVE-2022-37705 >Fix - https://github.com/zmanda/amanda/pull/196 > > >[2] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37703 >https://www.cve.org/CVERecord?id=CVE-2022-37703 >Fix - https://github.com/zmanda/amanda/pull/198 > >These 3 fixes are due for release as part of Amanda 3.5.3 within a week. > >Let us know if there are any other action items for us. > >Regards, > >AmandaTrusted > >Confidentiality Notice | The information transmitted by this email is intended >only for the person or entity to which it is addressed. This email may contain >proprietary, business-confidential and/or privileged material. If you are not >the intended recipient of this message, be aware that any use, review, >re-transmission, distribution, reproduction or any action taken in reliance >upon this message is strictly prohibited. If you received this in error, >please contact the sender and delete the material from all computers.
Bug#1018023: Update on this bug?
Thanks Matthew for the links. I will test this patch and let you to know whether the bug is fixed. Sincerely, Jose Matthew Vernon wrote: > Hi, > > Do you have plans to fix this before the bookworm freeze, please? > > I think netbsd at least have patched eterm to work with the newer > imlib; at least per the comment here > https://github.com/mej/Eterm/issues/4 > > That linked to > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/eterm/patches/ > > Which has a couple of patches that seem like they'd do the trick... > > Thanks, > > Matthew
Bug#1029204: zeroc-ice - consider building for all supported python 3 versions.
Hi, Are the other packages that do that? We can consider doing that if the changes are not too complicated. Cheers, Jose On Thu, Jan 19, 2023 at 4:57 PM Peter Green wrote: > Package: zeroc-ice > Severity: wishlist > > zeroc-ice currently builds a python library package which is only built > against > the default python 3 version. The result of this is that zeroc-ice is tying > together the "php 7.2" transition with the "python3 as default" transition. > > If zeroc-ice was to build it's python module for all supported python 3 > versions > then this coupling would be broken. > -- José Gutiérrez de la Concha ZeroC, Inc.
Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi, This is my first security update, can I ask what is the procedure or where is documented? Kind regards Jose M Calhariz On January 28, 2023 12:59:09 PM GMT+00:00, Salvatore Bonaccorso wrote: >Source: amanda >Version: 1:3.5.1-9 >Severity: grave >Tags: security upstream >Justification: user security hole >X-Debbugs-Cc: car...@debian.org, Debian Security Team > > >Hi, > >The following vulnerabilities were published for amanda. > >CVE-2022-37704[0], CVE-2022-37705[1]. > >If you fix the vulnerabilities please also make sure to include the >CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > >For further information see: > >[0] https://security-tracker.debian.org/tracker/CVE-2022-37704 >https://www.cve.org/CVERecord?id=CVE-2022-37704 >[1] https://security-tracker.debian.org/tracker/CVE-2022-37705 >https://www.cve.org/CVERecord?id=CVE-2022-37705 >[2] https://github.com/zmanda/amanda/issues/192 > >Please adjust the affected versions in the BTS as needed. > >Regards, >Salvatore
Bug#1027849: zeroc-ice: diff for NMU version 3.7.8-1.1
Hi Adrian, Seems didn't work, I will look into it. Cheers, Jose On Mon, Jan 9, 2023 at 10:21 PM Adrian Bunk wrote: > Control: tags 1027849 + pending > > Dear maintainer, > > I've prepared an NMU for zeroc-ice (versioned as 3.7.8-1.1) and uploaded > it to DELAYED/2. Please feel free to tell me if I should cancel it. > > cu > Adrian > -- José Gutiérrez de la Concha ZeroC, Inc.
Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules
Hi, can someone do a minimal patch proposing a way to solve this issue? So we can discuss the best way to solve it, before doing the big work of solving it. I am going to check why this is out of my radar. Kind regards Jose M Calhariz On December 4, 2022 4:56:51 AM GMT+00:00, Mathias Gibbens wrote: > I also would like to see this bug fixed, as a server I've got running >bookworm is spamming log events due to the default date format having >changed in rsyslog. > > Jose -- I'd be happy to help out by co-maintaining the logcheck >package. The logcheck repo is in the debian group on salsa, so by >convention technically it's open for any DD to contribute to, but I >don't want to just start doing uploads without first seeing if you >would have any objections. > > Stefan and Richard -- Hopefully we'll be able to get this bug >resolved pretty quickly. If you have patches for a suggested change or >(even better) a script to automate changing all the rule files, please >feel free to add it to this bug report, or open a pull request on >salsa. > >Mathias > > PS -- There might be an email loop, so I've specifically CC'ed Jose >on this email. The current Maintainer email address for logcheck is the >"magic" logch...@packages.debian.org address that will forward messages >to the package's maintainer, but because that's the exact same address >it might be looping/dropping messages. I'm not sure if there's logic in >place to also email "real" addresses listed as Uploaders for a package >or not
Bug#986405: dunst: After system boot, dunst.service is resolved to failed state until first notification is issued
Any update on this? As of dunst 1.8.1-1 (Debian testing/bookworm) this is still an issue. However, in my case, a coredump is also generated when it fails due to a SIGTRAP. $ systemctl --user status dunst.service × dunst.service - Dunst notification daemon Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; preset: enabled) Active: failed (Result: core-dump) since Mon 2022-09-26 05:38:17 UTC; 20min ago Docs: man:dunst(1) Process: 1296 ExecStart=/usr/bin/dunst (code=dumped, signal=TRAP) Main PID: 1296 (code=dumped, signal=TRAP) CPU: 22ms Sep 26 05:38:17 debian dunst[1296]: Invalid MIT-MAGIC-COOKIE-1 key Sep 26 05:38:17 debian dunst[1296]: WARNING: Cannot open X11 display. Sep 26 05:38:17 debian dunst[1296]: ERROR: [ get_x11_output:0065] Couldn't initialize X11 output. Aborting... Sep 26 05:38:17 debian systemd[1279]: Starting Dunst notification daemon... Sep 26 05:38:17 debian systemd-coredump[1306]: Process 1296 (dunst) of user 1000 dumped core. Module linux-vdso.so.1 with build-id c35c947b072ff69b395cd326b83b24630f2c5065 Module libmd.so.0 with build-id bfcdab3e6fabdc0d6f3e3e7d562330e80601a5af Module libbsd.so.0 with build-id 974e49045a7855a26d47583928fa20dbbfd4f530 Module libbrotlicommon.so.1 with build-id 3c671f721b58fd96b70ba426a215b3c43847bbf5 Module libblkid.so.1 with build-id d3e947026c74ed40701063d17ae59a2f6e51abcb Module libXdmcp.so.6 with build-id 1d12a8566670c95b1b02e341400060d2d825aade Module libXau.so.6 with build-id 84ffa90fee1b716cdc7d8349be47ed6ca4761b75 Module libbrotlidec.so.1 with build-id 1160b28572b6a6fc5674f5db1333716d4ba9e55f Module libdatrie.so.1 with build-id 57f62fe2ce6d6db200f0f8cfee3cc987b25a9e2f Module libuuid.so.1 with build-id 6b0f1c26b65771068f1daa425dae3f769ce41a6c Module libexpat.so.1 with build-id 0fa805792649d58f26fa59d23e9f5355ba67cca2 Module libgraphite2.so.3 with build-id 5b00ca1eda239ea043d7eae3b0fd4481560a907e Module libpcre2-8.so.0 with build-id 5aa43e3778622f4b95261331e97a45be5b87481d Module libffi.so.8 with build-id bb0fa5371874ba431e7cd9dc2df93922de436fa9 Module libselinux.so.1 with build-id 827b23e6391a3374fa79e36bca36c41c8e6d29e4 Module libmount.so.1 with build-id e29bc51dddfc4e370eb7eac9ff29df81efdbf22c Module libjpeg.so.62 with build-id 12da81e724cd81f4c71e54182d94d21f2bab27df Module libgmodule-2.0.so.0 with build-id 9f28f23ebfa524093fe5a2d1a8d086eaf3824645 Module libdl.so.2 with build-id 7a460055e0485a14f1d19cd8f8b8a0e77319fa44 Module libz.so.1 with build-id 19168f84642e8fe27700f92388598565e59048ee Module libXrender.so.1 with build-id 23dd581f5d93297dc5c508f03e224f9860af8217 Module libxcb-render.so.0 with build-id ca78dfc48f5a2593d9dc3b1d439740c6abad3f1c Module libxcb.so.1 with build-id 81156ba79b0ca3ca8d015453e333d16c3fcdc277 Module libxcb-shm.so.0 with build-id 77958cefc38a0b1edb4d0f4b76817b05ac6ec605 Module libpng16.so.16 with build-id 24720328fb61293ea32d8283c030fc0431082f65 Module libfreetype.so.6 with build-id 5d03f612aa76f7a175f1f23e5275809b0db692a4 Module libpixman-1.so.0 with build-id 2ba0d88f718a0fef93d759cfc90bc650cdee38ba Module libthai.so.0 with build-id 11b774e6b958fa6734f1a721527e1596e34ecd00 Module libfribidi.so.0 with build-id df6a1c7bc544c74c18a8635e3e65965a1fb529c3 Module libfontconfig.so.1 with build-id 3209e243ebaf08c058f6a17b9037cbdfecc3e72c Module libharfbuzz.so.0 with build-id d4a75db68352b8ea150e830e6720dc7f241b6c6c Module libpangof
Bug#1016386: RFS: scid/1:4.7.4+dfsg1-2 -- chess database with play and training functionality
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scid": * Package name: scid Version : 1:4.7.4+dfsg1-2 Upstream Author : Fulvio Benini * URL : http://scid.sf.net * License : Tklib, GPL-2.0 * Vcs : https://salsa.debian.org/josgalo-guest/scid Section : games The source builds the following binary packages: scid - chess database with play and training functionality scid-data - data files for scid, the chess database application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scid/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scid/scid_4.7.4+dfsg1-2.dsc Changes since the last upload: scid (1:4.7.4+dfsg1-2) unstable; urgency=medium . * debian/rules: - Pass OPTIMIZE variable without '-march=native' value to avoid build failures. Removed by mistake. P.D: The version in unstable (1:4.7.4+dfsg1-1) is not migrating to testing due to build failures. My mistake, I removed an important variable, sorry. Thanks and regards, pgpJUob7ucoZM.pgp Description: PGP signature
Bug#1015248: RFS: scid/1:4.7.4+dfsg1-1 -- chess database with play and training functionality
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scid": * Package name: scid Version : 1:4.7.4+dfsg1-1 Upstream Author : Fulvio Benini * URL : http://scid.sf.net * License : GPL-2.0, Tklib * Vcs : https://salsa.debian.org/josgalo-guest/scid Section : games The source builds the following binary packages: scid - chess database with play and training functionality scid-data - data files for scid, the chess database application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scid/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scid/scid_4.7.4+dfsg1-1.dsc Changes since the last upload: scid (1:4.7.4+dfsg1-1) unstable; urgency=medium . * New upstream version. * debian/control: - Bump to Standards-Version 4.6.1. No changes required. * debain/copyright: - Update upstream and debian package copyright years. * debian/patches: - 02_uninitialized-memory-access.patch. Remove patch applied upstream. - 01_Makefile.conf.diff. Refresh patch. * debian/rules: - Remove 'OPTIMIZE' option as it gets the same value from default. P.D: I know that three days ago a new upstream version (4.8) came out but I couldn't test it and I prefer to upload this tested version before packing the most recent. Thanks and regards, pgpfjUoFjfoGh.pgp Description: PGP signature
Bug#1015247: RFS: phalanx/25-1 -- Chess playing program
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "phalanx": * Package name: phalanx Version : 25-1 Upstream Author : Dusan Dobes * URL : https://sourceforge.net/projects/phalanx * License : GPL-2.0+, public-domain * Vcs : https://salsa.debian.org/josgalo-guest/phalanx Section : games The source builds the following binary packages: phalanx - Chess playing program To access further information about this package, please visit the following URL: https://mentors.debian.net/package/phalanx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/phalanx/phalanx_25-1.dsc Changes since the last upload: phalanx (25-1) unstable; urgency=medium . * New upstream version. * debian/compat: Remove file. * debian/copyright: Update copyright year and my e-mail. * debian/control: - Bump to Standards-Version 4.6.1. No changes required. - Change maintainer's e-mail. - Set Vcs* fields to Salsa. - Upgrade to debhelper compat 13. * debian/install: Book files should install to phalanx dir as they're only usable with the program. * debian/menu: Remove as menu system is deprecated (Policy >= 3.9.8). * debian/patches: - 03_makefile_DEFINES.diff: Refresh and renamed it to 01_makefile.patch - 04_PG_setboard_command.diff: Remove, applied upstream. - 05_PG_version-string.diff, 10_hardening-string-literal_search.diff, 12_hardening-string-literal_io.diff, 14_hardening-string-literal_book.diff, 16_hardening-pointer-sign_bcreate: Remove, not needed anymore. - 16_hardening-unused-but-set_endgame, 17_bcreate, 20_fix_linker_problem: Not applicable. - 02_dereference_pointer.patch: Add to fix not dereferenced pointer. (Closes: #1001069). Thanks to Michael Soyka. * debian/rules: - Add override_dh_auto_install to overwrite install dir. - Remove unnecessary dh argument. * debian/watch: - Upgrade to version 4 and handle latest version (XXV). Thanks and regards, pgpeqBFgGnfAY.pgp Description: PGP signature
Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb
On Tue, 8 Mar 2022 10:30:53 +0100 Matthias Klose wrote: > > For Ubuntu, I'm going to rename the old libtbb-dev and libtbb-doc packages to > libtbb2-dev and libtbb2-doc, not sure if that's something you also want to do in > Debian, but for the next Ubuntu release we need to ship both versions, or we > need to remove packages like numba. Following this up, the split of the libraries is breaking some common use cases in the robotics community, see https://github.com/ros-planning/navigation2/pull/2852#issuecomment-1072789270 . I think that it will handle nicely in Debian, for the next Ubuntu I've requested a sync from the experimental version (which is able to use new tbb) https://bugs.launchpad.net/ubuntu/+source/gazebo/+bug/1965780 Thanks.
Bug#1007222: transition: onetbb
On Mon, 14 Mar 2022 02:30:08 +0100 Matthias Klose wrote: > > > > I have not tested by myself, but I heard from an archlinux > > developer that this API bump breaks a lot packages. And > > some upstreams decided to disable or drop tbb support as > > a result. I guess we can take similar measures for short > > term workaround. > > "I heard from archlinux" is not good enough. I sent you email about this > without getting a reply, then filed #1006920, without getting a reply, now this > incomplete proposal. you may want to look at all the build rdeps for libtbb2-dev > in Ubuntu to get an overview what at least breaks: > > $ reverse-depends -b libtbb2-dev > > Reverse-Testsuite-Triggers > > * intel-mkl > > > > Reverse-Build-Depends > ... > > * gazebo > Speaking as the maintainer of Gazebo, upstream has released a new 11.10.2 version that is compatible with new tbb. I've uploaded it to experimental, it builds fine. The package should be ready for the transition as far as I can tell. Thanks guys for working on the transition.
Bug#1007709: xterm: Sometimes xterm last lines are not shown, amd64->arm64
Package: xterm Version: 366-1 Severity: normal X-Debbugs-Cc: j.fdez.jambr...@gr.ssr.upm.es Dear Maintainer, Sometimes xterm last lines are not shown, pressing enter forces them to appear. This happen with xterm running on an amd4 machine but displayed in a raspberry-4 machine, both running bullseye /stable This don't happen when runinng xterm on the same amd64 machineis and displaying it on amd64 machines I noticed it when running clusterssh, but running xterm directy with ssh (ssh -X amm64_machine /usr/bin/X11/xterm) give me to the same result. Maybe the problem is in the arm64 machine. This arm64 machine is an rapsberrypi-4 one, and this report is sent from it. Thanks very much for your atention. -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-12-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 xterm depends on: ii libc6 2.31-13+deb11u2 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libice6 2:1.0.10-1 ii libtinfo6 6.2+20201114-2 ii libutempter01.2.1-2 ii libx11-62:1.7.2-1 ii libxaw7 2:1.0.13-1.1 ii libxext62:1.3.3-1.1 ii libxft2 2.3.2-2 ii libxinerama12:1.1.4-2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.2.0-1 ii xbitmaps1.1.1-2.1 Versions of packages xterm recommends: ii x11-utils 7.7+5 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
Bug#997120: [Debian-med-packaging] Bug#997120:
On Wed, Feb 16, 2022 at 8:32 AM Emmanuel Promayon < emmanuel.proma...@univ-grenoble-alpes.fr> wrote: > Dear Jose and Andreas, > > On 14/02/2022 17:02, Andreas Tille wrote: > > Am Mon, Feb 14, 2022 at 12:18:47AM +0100 schrieb Jose Luis Rivero: > > You are welcome. This bug is preventing one of my packages (Gazebo) from > being > migrated to testing. Could we please upload a revision bump of the current > version to solve this issue while we work on 5.0.2? > > Hmmm, that's a bit tricky now. I've uploaded 5.0.2 to new[1]. May be > pinging #debian-ftp could help? (I'm hesitating a bit to do so myself > since I used that option recently a bit frequently.) > > Sorry about that: I did not notice that bug 997120 was blocking gazebo > (should there did not be a flag or message somewhere to alert about that? > Being quite inexperienced I might well as missed it...) > Let me know if (and how!) I can help with asking the ftpmaster team. > No worries Emmanuel, thanks for your offer to help. I have not pinged the ftp-master team yet, so you are on time to help the poor Gazebo to go to testing :) Thanks! >
Bug#997120:
Hello! > > Am Mon, Feb 07, 2022 at 10:57:36PM +0100 schrieb Emmanuel Promayon: > > Thank you very much for this patch, you are absolutely right: your patch > > fixes the problem! > > Possibly it fixes camitk for the current package in Debian. So thanks a > lot in any case. > You are welcome. This bug is preventing one of my packages (Gazebo) from being migrated to testing. Could we please upload a revision bump of the current version to solve this issue while we work on 5.0.2? > > It should also work perfectly well to make the last upstream version (5.0.2) > > build properly. Andreas started to check on last month but with your patch, > > it should work. > > I can confirm anyway that camitk version 5.0.2 builds well with ITK5 with > > the help of your patch. > > I've pushed an adapted patch to Git but I can't confirm that it builds. > May be you can have another look and compare the status in Git with your > local build? There are about 100 failed tests in the build time test > suite. Unfortunately salsa-ci chokes in source extration (no idea why > so I can only provide my local build log if you can't verify this. > I think that the problem in salsa is that the artifact handling between steps is broken due to the high number of files of camitk. We can probably copy the workaround that the linux kernel team has in place, see: https://www.decadent.org.uk/ben/blog/ci-for-the-debian-kernel-team.html Running the salsa catmik code in my sbuild run seems fine to me: """ 100% tests passed, 0 tests failed out of 526 ... +--+ | Summary | +--+ Autopkgtest: pass Build Architecture: amd64 Build Type: full Build-Space: 6680544 Build-Time: 743 Distribution: unstable Host Architecture: amd64 Install-Time: 74 Job: /home/jrivero/code/debian/camitk_5.0.2-1.dsc Lintian: warn Machine Architecture: amd64 Package: camitk Package-Time: 823 Piuparts: fail Source-Version: 5.0.2-1 Space: 6680544 Status: successful Version: 5.0.2-1 """ The Piuparts failure I think is something related to my local setup but compilation, test and autopkgtest seems fine to my eyes. Thanks.
Bug#997120:
Hi. I've been looking into the camitk compilation, I think I have a patch for it. The build is currently failing by trying to find the file CommandLineOptions.ixx.o. Problem is really in the line above where the compiler does not identify the file CommandLineOptions.ixx as a valid c++ file, so the object file is not being generated: """ c++: warning: /build/camitk-o5Au93/camitk-4.1.2/sdk/applications/testactions/CommandLineOptions.ixx: linker input file unused because linking not done "" The compiler can be informed about the format of the file by using -x c++ but the result won't compile at all since the file seems to be designed to be used in combination with other headers (other headers include .ixx at the end of the file). The code is in the compilation units via include in other headers, no reason to add it to CMake. Removing the .ixx makes the compilation work in an Sid sbuild environment. """ +--+ | Summary | +--+ Autopkgtest: pass Build Architecture: amd64 Build Type: full Build-Space: 6204608 Build-Time: 725 Distribution: unstable Host Architecture: amd64 Install-Time: 72 Job: /home/jrivero/code/debian/camitk_4.1.2-5.dsc Lintian: warn Machine Architecture: amd64 Package: camitk Package-Time: 801 Piuparts: pass Source-Version: 4.1.2-5 Space: 6204608 Status: successful Version: 4.1.2-5 """ Attached is the debdiff. camitk_4.2.2-5.debdiff Description: Binary data
Bug#738066: xinv3d: please provide a desktop file and icons
w c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ , 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs. If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library. If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/Makefile.am b/Makefile.am
new file mode 100644
index 000..20135d3
--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,30 @@
+# Makefile.am - build XINVADERS 3D - 3d Shoot'em up
+# Copyright (C) 2021 Jose Da Silva
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+#
+
+SUBDIRS = . desktop
+
+man_MANS = xinv3d.6
+
+bin_PROGRAMS = xinv3d
+xinv3d_SOURCES = aliens.c camera.c effects.c game.c object.c mat4x4.c player.c vec4x1.c main-x11.c
+noinst_HEADERS = camera.h defines.h externs.h game.h gtext.h mat4x4.h object.h system.h vec4x1.h
+xinv3d.$(OBJEXT): ${noinst_HEADERS}
+
+xinv3d_LDADD = -lX11 -lm
+
+EXTRA_DIST = main-dos.c main-w.c LICENSE README.dos README.win xinvaders3d.lsm xinv3d.6 ${noinst_HEADERS}
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 000..3466641
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,54 @@
+# -*- Autoconf -*-
+# Process this file with autoconf to produce a configure script.
+
+# Copyright (C) 2021 by Joe Da Silva
+
+AC_PREREQ(2.61)
+
+m4_define([xinv3d_version], [1.3.6-7])
+AC_INIT([xinv3d],[xinv3d_version],[packa...@qa.debian.org],
+ [xinv3d],[https://packages.debian.org/sid/xinv3d])
+AM_INIT_AUTOMAKE([foreign -Wall])
+AC_CANONICAL_BUILD
+AC_CANONICAL_HOST
+AC_USE_SYSTEM_EXTENSIONS
+AC_DEFINE(MOTIF, HAVE_MOTIF)
+AC_SUBST([XINV3D_VERSION],[xinv3d_version])
+AC_PROG_CC
+AC_PROG_RANLIB
+AC_PROG_INSTALL
+
+case $host in
+ *-freebsd* | *-openbsd*)
+ AC_DEFINE([GAME_LINUX_X11],1,[Build for X11])
+ ;;
+ *-apple-darwin*)
+ AC_DEFINE([GAME_LINUX_X11],1,[Build for X11])
+ ;;
+ *mingw*)
+ AC_DEFINE([GAME_WIN32],1,[Build for WIN_32])
+ ;;
+ *cygwin*)
+ AC_DEFINE([GAME_DOS_DJGPP],1,[Build for DOS])
+ ;;
+ *) AC_DEFINE([GAME_LINUX_X11],1,[Build for X11])
+esac
+
+# Required development include files (and associated libraries)
+AC_MSG_CHECKING([Check for X11 and required developer header files])
+AC_CHECK_HEADER([X11/Xlib.h],[],[AC_MSG_FAILURE([ERROR: Missing X11/Xlib.h, Please install Developer version of libx11-devel or lib64x11-devel],[1])])
+
+AC_CONFIG_FILES([Makefile xinv3d.pc desktop/Makefile])
+AC_OUTPUT
+AC_MSG_NOTICE([
+
+Configuration:
+
+ Source code location ${srcdir}
+ Build code location ${builddir}
+ Destination prefix ${prefix}
+ Host Operating System ${host}
+ Compiler ${CC}
+ Config CFLAGS "${CFLAGS}"
+
+])
diff --git a/desktop/128x128/xinv3d.png b/desktop/128x128/xinv3d.png
new file mode 100644
index ..547f121b99b8730e463584dd5ae0ab72a418205b
GIT binary patch
literal 1448
zcmds%*-MpC6vg))$|iW24jbUTN76RjiC)`XyLLtL$1bR
zYsFf1{?HZ`vt_ZY&MqjhDQrcoDBJ@IXRWeTu?l<01DLptIN%=;a0qIM0UDGz3Jx@e
zHl(4YE;+Z28cUef1qpv>i%Nt=kt^(i0-LPDiX4$N0st3|BWSoql*j{^xQ#f#1jBF$
zYKQ?EH-QBXG=?^$)s4uV#x`m!#l#RK{Glx>QFR0K$L}coiMo0ELvm1l?ryw(l#bC)
z$4%Qe?2vsAZumZybKrM^G#&>`3E{z$-^zay|M}b2z4cRx0#v)MbUiTs%k{URWh8_=FV@gIipQ@;hK~M-2BTTc`Ss^AyFb<3pWxLN
zjJAz_nLIsja9&++s5!hjBQjdK^IPMcC3GS9D&-vgJlu6Tb85ldNPNY_vZ3$oU(>=~
z%=><@`dwq$B%V{(^_o^wWlO{F`qnEIG~)GjA7~8*D#kYFw7k)9Fp}ClrYhz3nd=46
zyK;R=0O$`%zyU
p)0@G;*OPvn~+G#kgEp)cLHox=j;}h=plH$^$Ys)t`{s9d9yN>_>
literal 0
HcmV?d1
diff --git a/desktop/256x256/xinv3d.png b/des
Bug#1004435: transition: dart
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello! I'm the maintainer of dart, we have a new version in experimental that builds on the previous platforms supported, 6.12.1+dfsg4-8. I've run ratt and the expected dependency, Gazebo, builds just fine: https://release.debian.org/transitions/html/auto-dart.html https://build.osrfoundation.org/job/debian-ratt-builder/145/ """ 2022/01/26 13:50:25 dose-ceve(1) failed (exit status 64), falling back to interpreting Sources directly 2022/01/26 13:50:25 Loading sources index "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_experimental_main_source_Sources" 2022/01/26 13:50:26 Loading sources index "/var/lib/apt/lists/deb.debian.org_debian_dists_experimental_main_source_Sources" 2022/01/26 13:50:26 Found 1 reverse build dependencies 2022/01/26 13:50:26 Setting -sbuild_dist=experimental (from .changes file) 2022/01/26 13:50:26 Packages to rebuild gazebo_11.9.1+dfsg-7 gazebo_11.9.1+dfsg-7 2022/01/26 13:50:26 Building package 1 of 1: gazebo 2022/01/26 14:42:42 Build results: 2022/01/26 14:42:42 PASSED: gazebo """ Ben file: title = "dart"; is_affected = .depends ~ /\b(libdart\-collision\-bullet6\.12|libdart\-collision\-ode6\.12|libdart\-external\-convhull\-3d\-dev|libdart\-external\-imgui6\.12|libdart\-external\-lodepng6\.12|libdart\-external\-odelcpsolver6\.12|libdart\-gui\-osg6\.12|libdart\-gui6\.12|libdart\-optimizer\-ipopt6\.12|libdart\-optimizer\-nlopt6\.12|libdart\-utils\-urdf6\.12|libdart\-utils6\.12|libdart6\.12|python3\-dartpy|libdart\-collision\-bullet6|libdart\-collision\-ode6|libdart\-external\-imgui6|libdart\-external\-lodepng6|libdart\-external\-odelcpsolver6|libdart\-gui\-osg6|libdart\-gui6|libdart\-optimizer\-ipopt6|libdart\-optimizer\-nlopt6|libdart\-planning\-dev|libdart\-planning6|libdart\-utils\-urdf6|libdart\-utils6|libdart6|libkido\-dev|libkido\-gui\-dev|libkido\-gui\-osg\-dev|libkido\-gui\-osg0|libkido\-gui0|libkido\-optimizer\-ipopt\-dev|libkido\-optimizer\-ipopt0|libkido\-optimizer\-nlopt\-dev|libkido\-optimizer\-nlopt0|libkido\-planning\-dev|libkido\-planning0|libkido\-utils\-dev|libkido\-utils0|libkido0)\b/; is_good = .depends ~ /\b(libdart\-collision\-bullet6\.12|libdart\-collision\-ode6\.12|libdart\-external\-convhull\-3d\-dev|libdart\-external\-imgui6\.12|libdart\-external\-lodepng6\.12|libdart\-external\-odelcpsolver6\.12|libdart\-gui\-osg6\.12|libdart\-gui6\.12|libdart\-optimizer\-ipopt6\.12|libdart\-optimizer\-nlopt6\.12|libdart\-utils\-urdf6\.12|libdart\-utils6\.12|libdart6\.12|python3\-dartpy)\b/ is_bad = .depends ~ /\b(libdart\-collision\-bullet6|libdart\-collision\-ode6|libdart\-external\-imgui6|libdart\-external\-lodepng6|libdart\-external\-odelcpsolver6|libdart\-gui\-osg6|libdart\-gui6|libdart\-optimizer\-ipopt6|libdart\-optimizer\-nlopt6|libdart\-planning\-dev|libdart\-planning6|libdart\-utils\-urdf6|libdart\-utils6|libdart6|libkido\-dev|libkido\-gui\-dev|libkido\-gui\-osg\-dev|libkido\-gui\-osg0|libkido\-gui0|libkido\-optimizer\-ipopt\-dev|libkido\-optimizer\-ipopt0|libkido\-optimizer\-nlopt\-dev|libkido\-optimizer\-nlopt0|libkido\-planning\-dev|libkido\-planning0|libkido\-utils\-dev|libkido\-utils0|libkido0)\b/
Bug#1002286: Acknowledgement (transition: Gazebo + Ignition libraries)
On Mon, Jan 10, 2022 at 6:15 PM Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-01-10 17:41:17, Jose Luis Rivero wrote: > > I have received no negative feedback or blockers in the last 20 days, I'm > > afraid that we can not wait > > much longer since this bug is blocking others (like Dartsim transition). > My > > plan would be to proceed > > with the plan in the next few days unless feedback appears in the next 48 > > hours. > > These transitions are self-contained and gazebo is not in testing. I > think you can just go ahead with the uploads. > Thanks Sebastian for double checking. I proceeded yesterday with the upload of the whole set of 10 packages to unstable. As far as I can tell nothing is broken as of now. I'll close the bug in a few days if no problems appear. > > Cheers > > > > > Thanks! > > -- > Sebastian Ramacher >
Bug#1002286: Acknowledgement (transition: Gazebo + Ignition libraries)
I have received no negative feedback or blockers in the last 20 days, I'm afraid that we can not wait much longer since this bug is blocking others (like Dartsim transition). My plan would be to proceed with the plan in the next few days unless feedback appears in the next 48 hours. Thanks!
Bug#996563: ITP: ifcfg -- Python cross-platform network interface discovery (ifconfig/ipconfig/ip)
On Tue, Dec 21, 2021 at 9:36 AM Jochen Sprickerhof wrote: > Hi Jose, > > * Jose Luis Rivero [2021-10-15 14:36]: > >* Package name: ifcfg > > Version : 0.22 > > Upstream Author : BJ Dierkes > >* URL : https://github.com/ftao/python-ifcfg > >* License : BSD > > Programming Lang: Python > > Description : Python cross-platform network interface discovery > (ifconfig/ipconfig/ip) > > > >Ifcfg is a cross-platform library for parsing ifconfig and ipconfig > output in > >Python. It is useful for pulling information such as IP, Netmask, MAC > Address, > >Hostname, etc. > > I'm not sure this should be part of Debian. Parsing command line tools > is known to be brittle and ifconfig is a well known example for this. > There is `ip -json` to provide a more machine readable output but it > does not seem to be used by ifcfg. > > Also there is already python3-psutil and python3-netifaces in Debian, > providing the same information. > We were specifically looking into the features related to the interface flags which were not implemented in the psutil or netifaces at the time of writing. We changed the approach and find some dedicated time for trying to implement these missing features in psutils. https://github.com/giampaolo/psutil/pull/2037
Bug#999312: An updated version was just uploaded
Hi there! I've just uploaded an updated version of this package [0] which will hopefully fix this bug. I also already fulfilled the consequent RFS bug [1]. Could you provide some more time to let this package being properly reviewed and uploaded by a mentor before being automatically removed from the repository please? [0] https://mentors.debian.net/package/ssed/ [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002659 Thanks. Kind regards. -- Jose Antonio Quevedo Muñoz OpenPGP_signature Description: OpenPGP digital signature
Bug#1002659: RFS: ssed/3.6.2-8 - super sed stream editor
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ssed": * Package name: ssed Version : 3.6.2-8 Upstream Author : Paolo Bonzini * URL : http://sed.sf.net/grabbag/ssed/ * License : GPL-2+ Section : utils It builds those binary packages: ssed - super sed stream editor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ssed/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/ssed/ssed_3.62-8.dsc Changes since the last upload: * Added build-arch and build-indep targets (closes: #999312) * Added testsuite. * Added hardening flags to debian/rules. * Upgraded debian source format to 3.0 (quilt). * Updated standards version to 4.3.0. * Updated copyright to DEP-5 standard. * Updated debhelper dependency and compat version to 10. * Updated package priority from extra to optional. * Updated config.guess config.sub in config. * Removed autotools-dev dependency. * Removed initial article from description I would be glad if someone uploaded this package for me. Kind regards, -- Jose Antonio Quevedo Muñoz OpenPGP_signature Description: OpenPGP digital signature
Bug#1002451: lintian: False positive file-references-package-build-path
Package: lintian
Version: 2.114.0
Severity: normal
X-Debbugs-Cc: joseluisblan...@gmail.com
Dear Maintainer,
I found a false positive report of file-references-package-build-path for a C++
header file
included in a package, which does not contain any path at all.
The string detected by data/files/build-path-regex in our case is inside this
C++ comment:
/* Defined only if MRPT is being build/was built with precompiled
headers enabled */
I know it would be pretty complicated to discard C++ comments with a simple
regex, but
a possible solution is to change the most generic regex:
^build/
to something more specific capturing names like real build paths, for example:
`build/mrpt-mtM7nO/` => `build/[:alpha:]*-[:alpha:]{6}` or alike?
Thanks,
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-91-generic (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages lintian depends on:
ii binutils2.37-10
ii bzip2 1.0.8-5
ii diffstat1.64-1
ii dpkg1.20.9
ii dpkg-dev1.21.1
ii file1:5.41-2
ii gettext 0.21-4
ii gpg 2.2.27-2
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.40
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl0.48-1
ii libclass-xsaccessor-perl1.19-3+b7
ii libclone-perl 0.45-1+b1
ii libconfig-tiny-perl 2.27-1
ii libconst-fast-perl 0.014-1.1
ii libcpanel-json-xs-perl 4.27-1
ii libdata-dpath-perl 0.58-1
ii libdata-validate-domain-perl0.10-1.1
ii libdata-validate-uri-perl 0.07-1
ii libdevel-size-perl 0.83-1+b2
pn libdigest-sha-perl
ii libdpkg-perl1.21.1
ii libemail-address-xs-perl1.04-1+b3
ii libfile-basedir-perl0.09-1
ii libfile-find-rule-perl 0.34-1
ii libfont-ttf-perl1.06-1.1
ii libhtml-html5-entities-perl 0.004-1.1
ii libio-interactive-perl 1.023-1
ii libio-prompt-tiny-perl 0.003-1
ii libipc-run3-perl0.048-2
ii libjson-maybexs-perl1.004003-1
ii liblist-compare-perl0.55-1
ii liblist-someutils-perl 0.58-1
ii liblist-utilsby-perl0.11-1
ii libmoo-perl 2.005004-3
ii libmoox-aliases-perl0.001006-1.1
ii libnamespace-clean-perl 0.27-1
ii libpath-tiny-perl 0.120-1
ii libperlio-gzip-perl 0.19-1+b7
ii libperlio-utf8-strict-perl 0.008-1+b1
ii libproc-processtable-perl 0.634-1
ii libsereal-decoder-perl 4.018+ds-1+b1
ii libsereal-encoder-perl 4.018+ds-1+b1
ii libsort-versions-perl 1.62-1
ii libsyntax-keyword-try-perl 0.26-1
ii libterm-readkey-perl2.38-1+b2
ii libtext-glob-perl 0.11-2
ii libtext-levenshteinxs-perl 0.03-4+b8
ii libtext-markdown-discount-perl 0.13-1
ii libtext-xslate-perl 3.5.9-1
ii libtime-duration-perl 1.21-1
ii libtime-moment-perl 0.44-1+b3
ii libtimedate-perl2.3300-2
ii libunicode-utf8-perl0.62-1+b2
ii liburi-perl 5.10-1
ii libxml-libxml-perl 2.0134+dfsg-2+b1
ii libyaml-libyaml-perl0.83+ds-1
ii lzip1.22-4
ii lzop1.04-2
ii man-db 2.9.4-2
ii patchutils 0.4.2-1
ii perl [libencode-perl] 5.32.1-6
ii t1utils 1.41-4
ii unzip 6.0-26
ii xz-utils5.2.5-2
lintian recommends no packages.
Versions of packages lintian suggests:
pn binutils-multiarch
pn libtext-template-perl
-- no debconf information
Bug#1002160: ignition-transport: FTBFS: build-dependency not installable: libignition-msgs5-5 (= 5.1.0+dfsg-7+b1)
The problems should be fixed by resolving the transition from experimental to unstable of the whole Ignition family: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002286 On Tue, Dec 21, 2021 at 5:34 PM Lucas Nussbaum wrote: > Source: ignition-transport > Version: 8.0.0+dfsg-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > > +--+ > > | Install package build dependencies >| > > > +--+ > > > > > > Setup apt archive > > - > > > > Merged Build-Depends: cmake, pkg-config, debhelper-compat (= 12), > libgtest-dev, libprotoc-dev, libprotobuf-dev, protobuf-compiler, uuid-dev, > libzmq3-dev (>= 3.0.0), libignition-msgs-dev (>= 5), libignition-cmake-dev > (>= 2), libsqlite3-dev, build-essential, fakeroot > > Filtered Build-Depends: cmake, pkg-config, debhelper-compat (= 12), > libgtest-dev, libprotoc-dev, libprotobuf-dev, protobuf-compiler, uuid-dev, > libzmq3-dev (>= 3.0.0), libignition-msgs-dev (>= 5), libignition-cmake-dev > (>= 2), libsqlite3-dev, build-essential, fakeroot > > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > > Ign:1 copy:/<>/apt_archive ./ InRelease > > Get:2 copy:/<>/apt_archive ./ Release [957 B] > > Ign:3 copy:/<>/apt_archive ./ Release.gpg > > Get:4 copy:/<>/apt_archive ./ Sources [459 B] > > Get:5 copy:/<>/apt_archive ./ Packages [540 B] > > Fetched 1956 B in 0s (0 B/s) > > Reading package lists... > > Reading package lists... > > > > Install main build dependencies (apt-based resolver) > > > > > > Installing build dependencies > > Reading package lists... > > Building dependency tree... > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > libignition-msgs-dev : Depends: libignition-msgs5-5 (= 5.1.0+dfsg-7+b1) > but it is not going to be installed > > E: Unable to correct problems, you have held broken packages. > > apt-get failed. > > > The full build log is available from: > > http://qa-logs.debian.net/2021/12/20/ignition-transport_8.0.0+dfsg-3_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. > > -- > debian-science-maintainers mailing list > debian-science-maintain...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers >
Bug#1002286: transition: Gazebo + Ignition libraries
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello: The motivation for this bug is to manage the join transition from experimental of the packages corresponding to gazebo and the following ignition/sdformat libraries which are dependencies of gazebo (unstable version11.9.1+dfsg-2): - sdformat (unstable version 9.3.0) - ignition-transport (unstable version 8.0.0) - ignition-msgs (unstable version 5.1.0) - ignition-common (unstable version 3.14.0) - ignition-fuel-tools (unstable version 4.1.0) These set of dependencies have been moved to their own versioned source packages since ignition/sdformat versions need to be upgraded to new major versions but we need Gazebo to keep working (it uses exactly these set of major versions) until people migrate to Ignition (successor of Gazebo). So we have in experimental: - Gazebo 11.9.1+dfsg-4 depending now on new packages only in experimental: (note that packages are different from unstable, using major versions) - sdformat9 - ignition-transport8 - ignition-msgs5 (this is also in unstable) - ignition-common3 - ignition-fuel-tools4 Also in experimental, new versions of ignition packages are ready: - sdformat (unstable 9.3.0 -> experimental 12.3.0) - ignition-transport (unstable 8.0.0 -> experimental 8.2.1) - ignition-msgs (unstable 5.1.0 -> experimental 8.1.0) - ignition-common (unstable 3.14.0 -> experimental 4.4.0) - ignition-fuel-tools (unstable 4.1.0 -> experimental 7.0.0) The only packages listed in the ben tracker that could be broken by updating the current unstable ignition and sdformat are gazebo and their own interdependencies among this group. My plan would be to upload everything at once since we won't face any breakage if the following is correct: - gazebo would not be broken since it will use a new set of ignition packages - ignition/sdformat packages won't be broken since all them will be built using the new versions coming from experimental. Is this approach correct? Is there any side-effect that could appear that I'm not aware of? Thanks!
Bug#1001707: ITP: ignition-gui -- Ignition GUI ships with several widgets ready to use and offers a plugin interface which can be used to add custom widgets.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ignition-gui Version : 6.2.0 Upstream Author : Open Robotics * URL : https://github.com/ignitionrobotics/ign-gui * License : Apache2 Programming Lang: C++, Description : Ignition GUI ships with several widgets ready to use and offers a plugin interface which can be used to add custom widgets. Ignition GUI builds on top of Qt to provide widgets which are useful when developing robotics applications, such as a 3D view, plots, dashboard, etc, and can be used together in a convenient unified interface. Ignition GUI ships with several widgets ready to use and offers a plugin interface which can be used to add custom widgets.
Bug#1001706: ITP: ignition-physics -- Ignition Physics, a component of Ignition Robotics, provides an abstract physics interface designed to support simulation and rapid development of robot applicati
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ignition-physics Version : 5.1.0 Upstream Author : Open Robotics * URL : https://github.com/ignitionrobotics/ign-physics/ * License : Apache2 Programming Lang: C++ Description : Ignition Physics provides an abstract physics interface designed to support simulation and rapid development of robot applications. Ignition Physics, a component of Ignition Robotics, provides an abstract physics interface designed to support simulation and rapid development of robot applications.
Bug#1001705: ITP: ignition-rendering -- Ignition Rendering is a C++ library designed to provide an abstraction for different rendering engines. It offers unified APIs for creating 3D graphics applicat
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ignition-rendering Version : 6.1.0 Upstream Author : Open Robotics * URL : https://github.com/ignitionrobotics/ign-rendering/ * License : Apache2 Programming Lang: C++ Description : Ignition Rendering is a C++ library designed to provide an abstraction for different rendering engines. Ignition Rendering is a C++ library designed to provide an abstraction for different rendering engines. It offers unified APIs for creating 3D graphics applications. Ignition Rendering is a component in the ignition framework, a set of libraries designed to rapidly develop robot applications.
Bug#1001618: RM: mrpt [ppc64el] -- ROM; We want a newer mrpt version to get into unstable, then into testing, but we have this bug blocking it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100078
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: joseluisblan...@gmail.com
Bug#1000332: libopenblas64-openmp-dev: CMAKE cannot find OpenBLAS's files
Package: libopenblas64-openmp-dev Version: 0.3.13+ds-3 Severity: normal X-Debbugs-Cc: juanjose.garciarip...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I try to use OpenBLAS in various open software developments which are based on cmake builds * What exactly did you do (or not do) that was effective (or ineffective)? The CMAKE files from OpenBLAS are installed in deep locations that cmake 3.18 does not explore. This means that OpenBLAS cannot be used from CMAKE projects. A sample project cmake_minimum_required(VERSION 3.14) project(test) find_package(OpenBLAS REQUIRED) add_library(test "foo.c") target_link_libraries(test PUBLIC OpenBLAS::BLAS) will fail at configuration time (cmake -B ./build -S . -G "Unix Makefiles" --debug-find) * What was the outcome of this action? CMAKE fails to find OpenBLASConfig.cmake If invoked with --debug find, cmake will show that it searchers for the cmake files in shallower locations /usr/lib/x86_64-linux-gnu/openblas-pthread/OpenBLASConfig.cmake /usr/lib/x86_64-linux-gnu/openblas-pthread/openblas-config.cmake /usr/lib/x86_64-linux-gnu/openblas64-openmp/OpenBLASConfig.cmake /usr/lib/x86_64-linux-gnu/openblas64-openmp/openblas-config.cmake /usr/lib/x86_64-linux-gnu/openblas-pthread/cmake/OpenBLASConfig.cmake /usr/lib/x86_64-linux-gnu/openblas-pthread/cmake/openblas-config.cmake /usr/lib/x86_64-linux-gnu/openblas64-openmp/cmake/OpenBLASConfig.cmake /usr/lib/x86_64-linux-gnu/openblas64-openmp/cmake/openblas-config.cmake * What outcome did you expect instead? The OpenBLAS files should have been located in those directories for them to be located. Alternatively, Debian Bullseye should have shipped with a more recent version of CMAKE that searchers for OpenBLASConfig.cmake in deeper locations. *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.1 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.60.1-microsoft-standard-WSL2 (SMP w/32 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libopenblas64-openmp-dev depends on: ii libopenblas64-0-openmp 0.3.13+ds-3 libopenblas64-openmp-dev recommends no packages. libopenblas64-openmp-dev suggests no packages. -- no debconf information
Bug#998338: transition: urdfdom
On Tue, Nov 9, 2021 at 9:46 PM Sebastian Ramacher wrote: > On 2021-11-08 23:03:51, Sebastian Ramacher wrote: > > Control: tags -1 = confirmed > > > > On 2021-11-08 22:41:02 +0100, Jose Luis Rivero wrote: > > > Hi Sebastian: > > > > > > On Tue, Nov 2, 2021 at 5:39 PM Sebastian Ramacher < > sramac...@debian.org> > > > wrote: > > > > > > > Why is liburdfom-tools being renamed? This packages does not > contain a > > > > shared library. > > > > > > > > > > > No reason. Good catch. I've uploaded 3.0.0+ds-3 that revert the > > > liburdfdom-tools name change. > > > > > > Run ratt again with this new version: > > > https://build.osrfoundation.org/job/debian-ratt-builder/126/ > > > > > > 2021/11/08 17:25:15 PASSED: ros-collada-urdf > > > 2021/11/08 17:25:15 PASSED: ros-kdl-parser > > > 2021/11/08 17:25:15 PASSED: ros-urdf > > They all failed with: > Holy moly, the ratt build is using the 3.0.0 version and did not fail. https://build.osrfoundation.org/job/debian-ratt-builder/126/artifact/logs/buildlogs/ros-urdf_1.13.2-7/*view*/ I don't know why, I need to look deeper into the problem. Sorry for that Sebastian. > CMake Error at /usr/lib/x86_64-linux-gnu/cmake/urdf/urdfConfig.cmake:171 > (message): > Project 'rviz' tried to find library > '$<$>:-lurdfdom_sensor'. The library is neither ja > target nor built/installed properly. Did you compile project 'urdf'? Did > you find_package() it before the subdirectory containing its code is > included? > > This looks like a bug in urdfcom to me … three <, but only two >. > It is, indeed. Jochen sent the patch upstream https://github.com/ros/urdfdom/pull/164 and I have uploaded 3.0.0+ds-5 shipping it. Let's see if that fixes all the problems. > > Cheers > > > > > > Please go ahead > > > > Cheers > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > > > > > > Could you please proceed with the transition? > > > > > Thanks! > > > > > > > > > > > > > -- > > > > Sebastian Ramacher > > > > > > > > -- > > Sebastian Ramacher > > > > -- > Sebastian Ramacher >
Bug#998338: transition: urdfdom
Hi Sebastian: On Tue, Nov 2, 2021 at 5:39 PM Sebastian Ramacher wrote: > Why is liburdfom-tools being renamed? This packages does not contain a > shared library. > > No reason. Good catch. I've uploaded 3.0.0+ds-3 that revert the liburdfdom-tools name change. Run ratt again with this new version: https://build.osrfoundation.org/job/debian-ratt-builder/126/ 2021/11/08 17:25:15 Build results: 2021/11/08 17:25:15 PASSED: ros-collada-urdf 2021/11/08 17:25:15 PASSED: ros-rviz 2021/11/08 17:25:15 PASSED: sdformat 2021/11/08 17:25:15 PASSED: gazebo 2021/11/08 17:25:15 PASSED: ros-kdl-parser 2021/11/08 17:25:15 PASSED: ros-urdf 2021/11/08 17:25:15 PASSED: dart 2021/11/08 17:25:15 PASSED: ros-robot-state-publisher > Cheers > > > > > Could you please proceed with the transition? > > Thanks! > > > > -- > Sebastian Ramacher >
Bug#984063:
Hello! Gazebo maintainer here, affected by this RC bug. Looking into upstream repository there is a potential commit that can be used to patch this problem until new versions land in Debian: https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359a8fdb55304124823a3a8c9 Let me know if you need more help or assistance. Thanks!
Bug#984276:
Hello! Gazebo maintainer here, affected by this RC bug on opencolorio. I've looked in the problem and seems something easy to fix: diff --git a/src/core/ImageDesc.cpp b/src/core/ImageDesc.cpp index 63156c8..e96e758 100644 --- a/src/core/ImageDesc.cpp +++ b/src/core/ImageDesc.cpp @@ -57,8 +57,8 @@ OCIO_NAMESPACE_ENTER os << "gData=" << planarImg->getGData() << ", "; os << "bData=" << planarImg->getBData() << ", "; os << "aData=" << planarImg->getAData() << ", "; -os << "width=" << packedImg->getWidth() << ", "; -os << "height=" << packedImg->getHeight() << ", "; +os << "width=" << planarImg->getWidth() << ", "; +os << "height=" << planarImg->getHeight() << ", "; os << "yStrideBytes=" << planarImg->getYStrideBytes() << ""; os << ">"; } The repo in salsa seems to be a work in progress to get 2.x series into Debian, although not finished yet. We could apply this patch on top of the current version to fix this bug while the 2.x transition is being done. Let me know if you need more help. Thanks!
Bug#998385: ITP: flake8-import-order -- Flake8 and pylama plugin that checks the ordering of import statements.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: flake8-import-order Version : 0.18.1 Upstream Author : Alex Stapleton * URL : https://github.com/PyCQA/flake8-import-order * License : LGPLv3 Programming Lang: Python Description : Flake8 and pylama plugin that checks the ordering of import statements. A flake8 and Pylama plugin that checks the ordering of python imports. It does not check anything else about the imports. Merely that they are grouped and ordered correctly. In general stdlib comes first, then 3rd party, then local packages, and that each group is individually alphabetized, however this depends on the style used. Flake8-Import-Order supports a number of styles and is extensible allowing for custom styles.
Bug#998338: transition: urdfdom
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team: urdfdom library bumped the SOVERSION from 1.x to 3.x. I've run ratt in the Open Robotics buildfarm: https://build.osrfoundation.org/job/debian-ratt-builder/123/ 2021/10/29 11:58:02 Build results: 2021/10/29 11:58:02 PASSED: ros-kdl-parser 2021/10/29 11:58:02 PASSED: ros-urdf 2021/10/29 11:58:02 PASSED: gazebo 2021/10/29 11:58:02 PASSED: sdformat 2021/10/29 11:58:02 PASSED: ros-rviz 2021/10/29 11:58:02 PASSED: ros-robot-state-publisher 2021/10/29 11:58:02 PASSED: ros-collada-urdf 2021/10/29 11:58:02 PASSED: dart results seems fine. Ben file: title = "urdfdom"; is_affected = .depends ~ /\b(liburdfdom\-model\-state3\.0|liburdfdom\-model3\.0|liburdfdom\-sensor3\.0|liburdfdom\-tools3\.0|liburdfdom\-world3\.0|liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b/ is_good = .depends ~ /\b(liburdfdom\-model\-state3\.0|liburdfdom\-model3\.0|liburdfdom\-sensor3\.0|liburdfdom\-tools3\.0|liburdfdom\-world3\.0)\b/ is_bad = .depends ~ /\b(liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b.depends ~ /\b(liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b// Could you please proceed with the transition? Thanks!
Bug#996568: transition: fcl
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Dear Release Team:
I'm the maintainer of fcle, upstream has released 0.7.0
version some weeks ago. We have 0.7.0-2 in experimental, it builds
in all arches that it did before (hppa builder segfaults on compilation
but I doubt it has to do with version bump).
ratt rebuilt the dependencies it found, including DART, just fine:
https://build.osrfoundation.org/job/debian-ratt-builder/118/console
"""
2021/10/08 22:35:48 Building package 1 of 1: dart
2021/10/08 22:35:48 DEBUG - sbuild args
[]string{"--arch-all", "--dist=unstable", "--nolog", "dart_6.9.5-4",
"--extra-package=libfcl-dev_0.7.0-1_amd64.deb",
"--extra-package=libfcl0.7-dbgsym_0.7.0-1_amd64.deb",
"--extra-package=libfcl0.7_0.7.0-1_amd64.deb"}
2021/10/08 22:51:04 Build results:
2021/10/08 22:51:04 PASSED: dart
"""
Ben file:
title = "fcl";
is_affected = .depends ~ "libfcl0.6" | .depends ~ "libfcl0.7";
is_good = .depends ~ "libfcl0.7";
is_bad = .depends ~ "libfcl0.6";
Thanks!
Bug#996563: ITP: ifcfg -- Python cross-platform network interface discovery (ifconfig/ipconfig/ip)
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ifcfg Version : 0.22 Upstream Author : BJ Dierkes * URL : https://github.com/ftao/python-ifcfg * License : BSD Programming Lang: Python Description : Python cross-platform network interface discovery (ifconfig/ipconfig/ip) Ifcfg is a cross-platform library for parsing ifconfig and ipconfig output in Python. It is useful for pulling information such as IP, Netmask, MAC Address, Hostname, etc. Maintainership ideally would be shared with python team
Bug#996562: ITP: pytest-repeat -- pytest-repeat is a plugin for pytest that makes it easy to repeat a single test, or multiple tests, a specific number of times.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pytest-repeat Version : 0.9.1 Upstream Author : Bob Silverberg and others developers in pytest-repeat repo * URL : https://github.com/pytest-dev/pytest-repeat * License : MPLv2.0 Programming Lang: Python Description : pytest-repeat is a plugin for pytest that makes it easy to repeat a single test, or multiple tests, a specific number of times. Ideally maintainership will be shared with the debian-python team
Bug#996488: ITP: transforms3d -- Python code to convert between various geometric transformations
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: transforms3d Version : 0.3.1 Upstream Author : Matthew Brett and Christoph Gohlke * URL : https://github.com/matthew-brett/transforms3d.git * License : BSD-2, BSD-3 Programming Lang: Python Description : Code to convert between various geometric transformations The plan would be to maintain the package inside the debian-python team if possible.
Bug#995076: Adopt packages
On Thu, 07 Oct 2021 11:44:11 +0200 Christian Marillat wrote: On 05 oct. 2021 19:12, Andrew Starr-Bochicchio wrote: > Great news! Let me know if there's anything I can do to help you get > up to speed on the packages. qbittorrent 4.3.8 and libtorrent-rasterbar 2.0.4 have been uploaded to experimental. Christan Hi if possible, I would like to help with these packages. Cheers. Jose M. Abuin
Bug#994416: transition: urdfdom
On Sun, Sep 19, 2021 at 6:10 PM Sebastian Ramacher wrote: > The automatically generated tracker at > https://release.debian.org/transitions/html/auto-console-bridge.html > detects more reverse dependencies. Do those also build fine with the new > version of console-bridge? > Thanks Sebastian for pointing that out. I've fixed ceres-solver in the testing server and now it builds many more packages, I think all the ones in the auto transition slot are ready: 2021/10/04 22:25:04 Build results: 2021/10/04 22:25:04 PASSED: ros-rviz 2021/10/04 22:25:04 PASSED: ros-geometric-shapes 2021/10/04 22:25:04 PASSED: ros-opencv-apps 2021/10/04 22:25:04 PASSED: urdfdom 2021/10/04 22:25:04 PASSED: ros-resource-retriever 2021/10/04 22:25:04 PASSED: ros-navigation-msgs 2021/10/04 22:25:04 PASSED: ros-image-pipeline 2021/10/04 22:25:04 PASSED: ros-geometry 2021/10/04 22:25:04 PASSED: ros-common-msgs 2021/10/04 22:25:04 PASSED: ros-vision-opencv 2021/10/04 22:25:04 PASSED: ros-urdf 2021/10/04 22:25:04 PASSED: ros-roscpp-core 2021/10/04 22:25:04 PASSED: ros-image-common 2021/10/04 22:25:04 PASSED: ros-actionlib 2021/10/04 22:25:04 PASSED: ros-class-loader 2021/10/04 22:25:04 PASSED: ros-bond-core 2021/10/04 22:25:04 PASSED: ros-rosconsole-bridge 2021/10/04 22:25:04 PASSED: ros-pluginlib 2021/10/04 22:25:04 PASSED: ros-diagnostics 2021/10/04 22:25:04 PASSED: ros-interactive-markers 2021/10/04 22:25:04 PASSED: ros-perception-pcl 2021/10/04 22:25:04 PASSED: ros-rosconsole 2021/10/04 22:25:04 PASSED: mrpt 2021/10/04 22:25:04 PASSED: ros-pcl-msgs 2021/10/04 22:25:04 PASSED: ros-robot-state-publisher 2021/10/04 22:25:04 PASSED: ros-ros-comm 2021/10/04 22:25:04 PASSED: ros-laser-geometry 2021/10/04 22:25:04 PASSED: ros-dynamic-reconfigure 2021/10/04 22:25:04 PASSED: sdformat 2021/10/04 22:25:04 PASSED: ros-ros-comm-msgs 2021/10/04 22:25:04 PASSED: ros-nodelet-core 2021/10/04 22:25:04 PASSED: ros-geometry2 2021/10/04 22:25:04 PASSED: ros-collada-urdf 2021/10/04 22:25:04 PASSED: ros-kdl-parser https://build.osrfoundation.org/job/debian-ratt-builder/110/console Let me know if you see other problems. > > Cheers > > > > > Ben file: > > > > title = "urdfdom"; > > is_affected = .depends ~ "libconsole-bridge0.4" | .depends ~ > "libconsole-bridge1.0"; > > is_good = .depends ~ "libconsole-bridge1.0"; > > is_bad = .depends ~ "libconsole-bridge0.4"; > > > > Thanks! > > > > -- > Sebastian Ramacher >
Bug#995218: xinv3d new upstream release
Package: xinv3d Version: 1.3.6 New upstream release of orphaned Debian Package xinv3d v1.3.6 located here: https://github.com/JoesCat/xinv3d/releases git repo located here: https://github.com/JoesCat/xinv3d/ Note: lacking prior git or SVN history, this git repo is approximate, but not historically correct (as was) - this is the best I was able to do based on the existing Debian xinv3d install files. This version fixes existing bugs and adds existing patch, therefore also is bumped from version 1.3.6 to 1.4.0 More information here: https://lists.debian.org/debian-devel-games/2021/09/msg1.html Thanks, Joe
Bug#994893: ITP: ogre-next -- Ogre is a 3D graphics rendering engine (next generation)
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ogre-next Version : 2.2.5 Upstream Author : https://github.com/OGRECave/ogre-next/blob/master/AUTHORS * URL : https://github.com/OGRECave/ogre-next * License : MIT Programming Lang: C++ Description : Ogre is a 3D graphics rendering engine (next generation) In Debian we already have Ogre-1.x in the form of ogre-1.9 and ogre-1.10. The Ogre project was divided into Ogre and Ogre-next, this last one hosts the old 2.x branches. Both are maintained and developed and incompatible with each other. For more details see: https://www.ogre3d.org/about/what-version-to-choose The idea is to have both projects in Debian since nowadays they are totally independent from each other. To maintain it in Debian, together with Manuel A. Fernandez Montecelo, we created the ogre-team inside salsa some years ago. https://salsa.debian.org/ogre-team
Bug#994416: transition: urdfdom
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team: I'm the maintainer of console-bridge package, upstream has released 1.0 version some weeks ago. We have 1.0.1+dfsg2-2 in experimental, it builds in all arches: https://buildd.debian.org/status/package.php?p=console-bridge&suite=experimental I have run ratt in the Open Robotics buildfarm and dependencies looks fine: https://build.osrfoundation.org/job/debian-ratt-builder/86/ """ 2021/09/15 14:11:16 Loading changes file "console-bridge_1.0.1+dfsg2-2_amd64.changes" 2021/09/15 14:11:16 - 3 binary packages: libconsole-bridge-dev libconsole-bridge1.0 libconsole-bridge1.0-dbgsym 2021/09/15 14:11:16 Corresponding .debs (will be injected when building): 2021/09/15 14:11:16 libconsole-bridge-dev_1.0.1+dfsg2-2_amd64.deb 2021/09/15 14:11:16 libconsole-bridge1.0-dbgsym_1.0.1+dfsg2-2_amd64.deb 2021/09/15 14:11:16 libconsole-bridge1.0_1.0.1+dfsg2-2_amd64.deb 2021/09/15 14:11:16 Setting -dist=sid (from .changes file) 2021/09/15 14:11:18 Loading sources index "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_sid_main_source_Sources.lz4" 2021/09/15 14:11:19 Setting -sbuild_dist=unstable (from .changes file) 2021/09/15 14:11:19 Building package 1 of 10: ros-dynamic-reconfigure 2021/09/15 14:15:57 Building package 2 of 10: ros-geometry 2021/09/15 14:20:45 Building package 3 of 10: ros-rosconsole-bridge 2021/09/15 14:24:26 Building package 4 of 10: ros-roscpp-core 2021/09/15 14:27:48 Building package 5 of 10: urdfdom 2021/09/15 14:30:09 Building package 6 of 10: ros-bond-core 2021/09/15 14:34:10 Building package 7 of 10: ros-class-loader 2021/09/15 14:37:56 Building package 8 of 10: ros-geometry2 2021/09/15 14:42:58 Building package 9 of 10: ros-ros-comm 2021/09/15 14:50:07 Building package 10 of 10: ros-actionlib 2021/09/15 14:58:21 Build results: 2021/09/15 14:58:21 PASSED: ros-roscpp-core 2021/09/15 14:58:21 PASSED: urdfdom 2021/09/15 14:58:21 PASSED: ros-class-loader 2021/09/15 14:58:21 PASSED: ros-geometry2 2021/09/15 14:58:21 PASSED: ros-ros-comm 2021/09/15 14:58:21 PASSED: ros-actionlib 2021/09/15 14:58:21 PASSED: ros-geometry 2021/09/15 14:58:21 PASSED: ros-rosconsole-bridge 2021/09/15 14:58:21 PASSED: ros-bond-core 2021/09/15 14:58:21 PASSED: ros-dynamic-reconfigure """ Ben file: title = "urdfdom"; is_affected = .depends ~ "libconsole-bridge0.4" | .depends ~ "libconsole-bridge1.0"; is_good = .depends ~ "libconsole-bridge1.0"; is_bad = .depends ~ "libconsole-bridge0.4"; Thanks!
Bug#981446: Possible adoption of logcheck
Hi, On Thu, Sep 02, 2021 at 09:55:36PM +0200, Hannes von Haugwitz wrote: > Hi Jose, > > On Mon, Aug 30, 2021 at 07:58:21PM +0100, Jose M Calhariz wrote: > > I am a user of logckeck as I use on all my machines that I sysadmin > > and I maintain some packages on Debian like for example at and amanda. > > > > As now I would like to offer my help to package and fix logcheck as a > > learning experience for a possibility in the future to be the > > maintainer of logcheck. > > This is great news! > > The logcheck VCS repo is in the `debian` group on salsa.debina.org[0]; > so (as DD) you can just start to work on the package. > > Please let me know if you have any questions or want some review. Thank you for accepting me. For now my question is: Who is the upstream that you are using? > > Best regards > > Hannes > > [0] https://salsa.debian.org/debian/logcheck/ > Kind regards Jose M Calhariz -- -- A história sugere que o capitalismo é uma condição necessária para a liberdade política. Evidentemente, não é uma condição suficiente --Milton Friedmann signature.asc Description: PGP signature
Bug#981446: Possible adoption of logcheck
Hi, I am a user of logckeck as I use on all my machines that I sysadmin and I maintain some packages on Debian like for example at and amanda. As now I would like to offer my help to package and fix logcheck as a learning experience for a possibility in the future to be the maintainer of logcheck. Kind regards Jose M Calhariz -- -- Você faria papel de trouxa? A Betty Faria. signature.asc Description: PGP signature
Bug#985421: Adding DEP8 tests for at package
Hi, Now I have the repo full updated and I am preparing a new upstream release of at, with many changes and bug fixes. Do you mind to do a MR at salsa? Kind regards Jose M Calhariz On 17/03/2021 20:57, Utkarsh Gupta wrote: > Source: at > Version: 3.1.23-1.1 > Severity: normal > Tags: patch > > Hello, > > Since at is missing DEP8 tests, I'd like to add them. I wanted to > propose an MR on salsa but the git history isn't in sync with what's > uploaded to the archive, so asking here. > > I've prepared the basic testing script to ensure that there's no > regression. I initially submitted this in Ubuntu but want to get it > merged and uploaded here. > > Attaching the debdiff here for your review. Let me know what you think > about this. Can I proceed with the upload? > > > - u
Bug#993142: ITP: flake8-comprehensions -- flake8 plugin that helps you write better list/set/dict comprehensions.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: flake8-comprehensions Version : 3.6.1 Upstream Author : Adam Johnson * URL : https://github.com/adamchainz/flake8-comprehensions * License : MIT Programming Lang: Python Description : flake8 plugin that helps you write better list/set/dict comprehensions. Package adds check for the flake8 linter related to list/set/dict comprehensions. Examples are: Unnecessary generator, Unnecessary list comprehension, Unnecessary call, etc.
Bug#993139: ITP: flake8-class-newline -- flake8 Extension to lint for a method newline after a Class definition
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: flake8-class-newline Version : 1.6.0 Upstream Author : Alexander van Eck * URL : https://github.com/AlexanderVanEck/flake8-class-newline * License : MIT Programming Lang: Python Description : flake8 Extension to lint for a method newline after a Class definition flake8 Extension to lint for a method newline after a Class definition PEP8 says we should surround every class method with a single blank line. See https://www.python.org/dev/peps/pep-0008/#blank-lines However flake8 is ambiguous about the first method having a blank line above it. This plugin was made to enforce the blank line just after the method declaration.
Bug#992887: xball new upstream release
Package: xball Version: 3.0.1 New upstream release of orphaned Debian Package xball v3.0.1 located here: https://github.com/JoesCat/xball/releases/tag/v3.1.0 git repo located here: https://github.com/JoesCat/xball/ Note: lacking prior git or SVN history, this git repo is approximate, but not historically correct (as was) - the best I was able to do based on the existing Debian xball install files. More information here: https://lists.debian.org/debian-devel-games/2021/08/msg5.html Thanks, Joe
Bug#972435: amanda: Please add support for TI RPC implementation
Hi, thank you for the patch, I am working to validate that everything works. Kind regards Jose M Calhariz On 21/08/2021 19:04, Aurelien Jarno wrote: > control: tag -1 + ftbfs > control: severity -1 serious > > On 2020-10-18 15:19, Aurelien Jarno wrote: >> Source: amanda >> Version: 1:3.5.1-5 >> Severity: normal >> Tags: patch upstream >> >> Dear maintainer, >> >> The glibc SunRPC implementation has been marked obsolete for some time. >> It will get removed from glibc in version 2.32 that has been released a >> few weeks ago. The TI RPC implementation should be used instead, which >> also brings new features (IPv6, Kerberos support, ...). >> >> You will find attached a patch taken from Fedora to add support for the >> TI RPC implementation in case the SunRPC implementation is not >> available. Would it be possible to apply it to the Debian package so >> that amanda continues to build when the glibc SunRPC gets removed. > Now that rpc support has been removed from glibc 2.31-14, amanda fails > to build from source and needs the patch attached to this bug report to > build. I am therefore increasing the severity. > > Regards, > Aurelien >
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, Aug 18, 2021 at 10:17:36PM +0530, Ritesh Raj Sarraf wrote: > On Wed, 2021-08-18 at 19:35 +0530, Ritesh Raj Sarraf wrote: > > On Wed, 2021-08-18 at 13:32 +0100, Jose M Calhariz wrote: > > > I was expecting to be easy to collect the info in one or 2 files, but > > > I am wrong. I have 3 targets with multipath for 2 of them and I am > > > not certain what is active. I have multipath active, I am certain of > > > that, because of the device I am mouting: > > > /dev/mapper/mpath-X-part1 > > > > > > So I am expecting you need all files inside /etc/iscsi and some > > > run-time info? > > > > I am asking this information just for the sake of this task, to > > ascertain why it failed in the first 30 seconds. > > > > Since this worked for you, later, when you increased the timeout to 120 > > seconds; there's not much to do I suppose. But yes, from this bug > > report's sake, having that information clarified will be good. Giving that I have seen this bug before with my machines, it is only the first time I am reporting and being the first reporter so I am with you, this is some setting in my site or my machine. With more reasearch with help from the local specialist I found a an extra iSCSI setup to a local appliance that I not longer need. So I remove it from /etc/iscsi. Doing again a: dpkg --configure -a Setting up open-iscsi (2.1.3-5) ... open-iscsi postinst: since the check in preinst some iSCSI sessions have failed. -> will wait 30s for automatic recovery Processing triggers for initramfs-tools (0.140) ... update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64 This time it succeeds. So this probably is a problem on my machine. May I suggest for you to increase the timeout from 30s to 60 or 120s? Mine reasoning is that my machine boots fast enough for me not investigate more my iSCSI connections, but probably the iSCSI appliance is giving authentication timeout and so the increased need for a longer timeout on open-iscsi postinst. Making the package more robust. We may talk more about this problem and I offer my time and machine to do research on to improve the package if you see benefit on that. But I will not keep the bug open if you want to close it. Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#984182:
Upstream bug: https://github.com/ignitionrobotics/ign-common/issues/239
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, Aug 18, 2021 at 12:54:13PM +0100, Jose M Calhariz wrote: > On Wed, Aug 18, 2021 at 01:57:35PM +0530, Ritesh Raj Sarraf wrote: > > On Tue, 2021-08-17 at 19:02 +0100, Jose M Calhariz wrote: > > > > Did you change/tweak any of the default timeout values ? > > > > > > > > > > Most probably, it is not me that usually setup the iSCSI connections. > > > What values do you want me to look into it and where? > > > > All information should be available under `/etc/iscsi`. > > There will be per target database created under that folder. And those > > will have all the finer session and replacement timeouts defined. They > > are usually generated/updated through the `iscsiadm` utility during > > discovery. > > > > PS: That db may also include CHAP secrets, if you set any. > > > > OK, > > I will send to you the iSCSI setup without secrets and we will put in > the bug report the relevant info. > > Kind regards > Jose M Calhariz > > Hi, I was expecting to be easy to collect the info in one or 2 files, but I am wrong. I have 3 targets with multipath for 2 of them and I am not certain what is active. I have multipath active, I am certain of that, because of the device I am mouting: /dev/mapper/mpath-X-part1 So I am expecting you need all files inside /etc/iscsi and some run-time info? Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, Aug 18, 2021 at 01:57:35PM +0530, Ritesh Raj Sarraf wrote: > On Tue, 2021-08-17 at 19:02 +0100, Jose M Calhariz wrote: > > > Did you change/tweak any of the default timeout values ? > > > > > > > Most probably, it is not me that usually setup the iSCSI connections. > > What values do you want me to look into it and where? > > All information should be available under `/etc/iscsi`. > There will be per target database created under that folder. And those > will have all the finer session and replacement timeouts defined. They > are usually generated/updated through the `iscsiadm` utility during > discovery. > > PS: That db may also include CHAP secrets, if you set any. > OK, I will send to you the iSCSI setup without secrets and we will put in the bug report the relevant info. Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Tue, Aug 17, 2021 at 11:13:36PM +0530, Ritesh Raj Sarraf wrote: > Hello Jose, Hi > > Good to hear from you. I recollect having met you, in person, at > Debconf Heidelberg or Debconf Capetown. I hope you are doing > good. :-) Yes, I am fine and you? I was in both DebConfs but I remember meeting you in Capetown. > > On Tue, 2021-08-17 at 16:27 +0100, Jose M Calhariz wrote: > > During upgrades of open-iscsi on my environment it fails to run > > postinst with success. I got the following messages: > > > > Setting up open-iscsi (2.1.3-5) ... > > open-iscsi postinst: since the check in preinst some iSCSI sessions > > have > > failed. -> will wait 30s for automatic recovery > > open-iscsi postinst: some sessions are still in failed state -> > > iscsid > > will be restarted regardless, since that may > > actually help with the session recovery. > > dpkg: error processing package open-iscsi (--configure): > > installed open-iscsi package post-installation script subprocess > > returned error exit status 1 > > > > > > I have tried to change the postinst to wait for more time, for > > example > > 120s and it worked, after 40 seconds of wait. > > Hmmm. Usually, the sessions should recover within a couple of seconds. > IIRC, the check is every 5 seconds. > > > Did you change/tweak any of the default timeout values ? > Most probably, it is not me that usually setup the iSCSI connections. What values do you want me to look into it and where? Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992367: ITP: flake8-builtins -- Check for python builtins being used as variables or parameters
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero * Package name: flake8-builtins Version : 1.5.3 Upstream Author : Gil Forcada Codinachs * URL : https://github.com/gforcada/flake8-builtins * License : GPL2 Programming Lang: Python Description : Check for python builtins being used as variables or parameters Part of the available set of extensions for flake8
Bug#992366: ITP: flake8-blind-except -- A flake8 extension that checks for blind, catch-all except: and except Exception: statements.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero * Package name: flake8-blind-except Version : 0.2.0 Upstream Author : Elijah Andrews * URL : https://github.com/elijahandrews/flake8-blind-except * License : MIT Programming Lang: python Description : A flake8 extension that checks for blind, catch-all except: and except Exception: statements. As of pycodestyle 2.1.0, "E722 do not use bare except, specify exception instead" is built-in. However, bare Exception and BaseException are still allowed. This extension flags them as B902. Using except without explicitly specifying which exceptions to catch is generally considered bad practice, since it catches system signals like SIGINT. You probably want to handle system interrupts differently than exceptions occuring in your code. It's also usually better style to have many small try-except blocks catching specific exceptions instead of a giant try: block with a catch-all except: at the bottom. It's also nicer to your fellow programmers to be a bit more specific about what exceptions they can expect in specific parts of the code, and what the proper course of action is when they occur.
Bug#992365: ITP: ignition-plugin -- Library for registering plugin libraries and dynamically loading them at runtime
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero * Package name: ignition-plugin Version : 1.2.0 Upstream Author : Open Robotics * URL : https://github.com/ignitionrobotics/ign-plugin/ * License : Apache-2 Programming Lang: C++ Description : Library for registering plugin libraries and dynamically loading them at runtime Library for registering plugin libraries and dynamically loading them at runtime. Ignition Plugin is a component in the ignition framework, a set of libraries designed to rapidly develop robot applications.
Bug#992347: open-iscsi on upgrades fail to finish postinst script
Package: open-iscsi Version: 2.1.3-5 Severity: normal During upgrades of open-iscsi on my environment it fails to run postinst with success. I got the following messages: Setting up open-iscsi (2.1.3-5) ... open-iscsi postinst: since the check in preinst some iSCSI sessions have failed. -> will wait 30s for automatic recovery open-iscsi postinst: some sessions are still in failed state -> iscsid will be restarted regardless, since that may actually help with the session recovery. dpkg: error processing package open-iscsi (--configure): installed open-iscsi package post-installation script subprocess returned error exit status 1 I have tried to change the postinst to wait for more time, for example 120s and it worked, after 40 seconds of wait. Kind regards Jose M Calhariz -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_IL:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages open-iscsi depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13 ii libisns0 0.100-3 ii libkmod2 28-1 ii libmount1 2.36.1-8 ii libopeniscsiusr2.1.3-5 ii libssl1.1 1.1.1k-1 ii libsystemd0247.3-6 ii udev 247.3-6 open-iscsi recommends no packages. open-iscsi suggests no packages. -- debconf information: open-iscsi/upgrade_recovery_error: open-iscsi/upgrade_even_with_failed_sessions: open-iscsi/downgrade_and_break_system: open-iscsi/remove_even_with_active_sessions:
Bug#990197: unblock: amanda/3.5.1-6
On 22/06/2021 22:15, Michael Biebl wrote: > Am 22.06.21 um 21:49 schrieb Jose M Calhariz: > >>> My first build was with MAILER only on config and tested on a >>> bullseye >>> server. > > This appears to be correct/sufficient > >>> Then I was point into #475771 and that my change was not complete >>> enough >>> so I > > I don't think you need to set it for MAKE. I think it was done so > mistakenly in the past. > > > If it helps, there is packaging/deb/rules which also sets MAILER only > during ./configure. > So you prefer the following patch and that I upload a 3.5.1-7 with only that change, right? I am learning to do my first unblock request. git show d8821280299fe30c64d98635b546c87318ee47a5 commit d8821280299fe30c64d98635b546c87318ee47a5 Author: Jose M Calhariz Date: Sun Jun 20 21:34:41 2021 +0100 Use command mail instead of Mail. diff --git a/debian/rules b/debian/rules index 6f7e9c7..ad6a1a3 100755 --- a/debian/rules +++ b/debian/rules @@ -41,7 +41,8 @@ confflags = --prefix=/usr \ dh $@ --with autoreconf --parallel override_dh_auto_configure: - LIBS="-lssl" dh_auto_configure -- $(confflags) + # MAILER: Fix for #296022, #475771 and #990080 + MAILER="/usr/bin/mail" LIBS="-lssl" dh_auto_configure -- $(confflags) override_dh_install: sed -i "/dependency_libs/ s/'.*'/''/" `find debian/tmp -name '*.la'`
Bug#990197: unblock: amanda/3.5.1-6
On 22/06/2021 18:08, Jose M Calhariz wrote: > On 22/06/2021 17:53, Michael Biebl wrote: >> Am 22.06.21 um 18:39 schrieb Jose M Calhariz: >>> On 22/06/2021 17:13, Michael Biebl wrote: >>>> Am 22.06.21 um 16:55 schrieb Jose M Calhariz: >>>>> +override_dh_auto_build: >>>>> + # MAILER: Fix for #296022, #475771 and #990080 >>>>> + MAILER="/usr/bin/mail" dh_auto_build >>>> Are you sure this bit is necessary? >>>> Once MAILER has been set by ./configure, the generated Makefiles >>>> should have MAILER set up properly. >>>> >>>> Can you grep over the generate Makefiles if MAILER is set correctly? >>>> >>>> Michael >>>> >>> I have included that diff, because of #475771. So in the past it > was >>> necessary. >>> >>> Doing grep in all Makefiles I am seeing this: >>> >>> DEFAULT_MAILER = /usr/bin/mail >>> MAILER = /usr/bin/mail >>> >>> >>> I can upload a new package with your request, but because of #475771 I >>> prefer amanda/3.5.1-6 as is. It is your call. >> Well, if you drop the override_dh_auto_build bit, does the resulting >> deb work or not? I assume you have tested the patch? >> >> > It works wit both diffs Can you follow #990080 and the thread in > there? Do you want me > > to push my git repo with the commits for both tries? > > > My first build was with MAILER only on config and tested on a > bullseye > server. > > Then I was point into #475771 and that my change was not complete enough > so I > > have done another build and I tested with the extended diff under the > same server. > > > Kind regards > > Jose M Calhariz > > >
