Bug#1080175: funnelweb (3.2-6) uploaded to DELAYED=10
Hi Yann, Am Sun, Sep 22, 2024 at 11:54:17PM +0200 schrieb Yann Dirson: > No objection to the ITS. Thanks for confirming. > BTW I have already wondered if it would not make sense to simply drop this > package entirely, given the small popcon score and the fact it is dead > upstream. I admit the same idea came to my mind as well. However, the Bug of the Day initiative is also kind of demonstration how to triage bugs and update packages. For this purpose the update was fine. If you prefer to remove the package from Debian just do so. Kind regards and thanks for maintaining the package over the years Andreas. -- https://fam-tille.de
Bug#1080498: RFS: apt-listchanges/4.5 [ITA] -- package change history notification tool
On 2024-09-22 Jonathan Kamens wrote: > On 9/6/24 4:36 AM, Jeroen Ploemen wrote: [...] > > Any particular reason for continuing to upload to experimental only, > > now that version 4.x has been out for about a year with nothing major > > reported in the bug tracker? > You're correct, I believe it's time for unstable. Hello, imho 1055780 is a very major issue. (The new upload is supposed to handle that.) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1082598: ITS: xosd
Source: xosd Version: 2.2.14-2.1 Severity: normal X-Debbugs-Cc: Philipp Matthias Hahn , 1082...@bugs.debian.org, Package Salvaging Team Hi I'm interested in salvaging your package xosd, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - NMUs, especially if there has been more than one NMU in a row. - Bugs filed against the package do not have answers from the maintainer. - Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged. - There are QA issues with the package. I've set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/xosd [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1080175: funnelweb (3.2-6) uploaded to DELAYED=10
Hi Yann, as per ITS bug I have uploaded funnelweb to DELAYED=10 queue. Please let me know if you want me to remove this upload before it hits unstable. Kind regards Andreas. -- https://fam-tille.de
Bug#1082512: ITS: kbdd
Dear Stanislav, Am Sun, Sep 22, 2024 at 09:04:49AM +0100 schrieb Stanislav Maslovski: > Dear Andreas, > > Thank you for your message. I will check what does the new version > offer. Thanks a lot for your quick response. > In fact, the version that is currently packaged in Debian works > just fine. I am using it myself on daily basis, and I had no problems > with it. Also, as you can see, there have been no functional bugs > reported for kbdd for many years. I agree there are no functional bugs. However, the new version incorporates some Debian patches - so it makes sense to rather use the latest version. I'm actually unsure about the last remaining patch which I deactivated for the moment. It seems upstream has found a different solution. Its very good to know you are active and can verify the functionality. > I may need your help later when uploading the new version through > debian-mentors if all goes well. I'm perfectly fine to sponsor your package without doing the "detour" via mentors. Just ping me if you are happy with the status of the Git repository. > Thanks, You are perfectly welcome and thanks again for your quick response. Kind regards Andreas. > On Sat, Sep 21, 2024 at 01:15:08PM +0200, Andreas Tille wrote: > > Source: kbdd > > Version: 0.6-4 > > Severity: normal > > X-Debbugs-Cc: Stanislav Maslovski , > > 673...@bugs.debian.org, 836...@bugs.debian.org, 1079...@bugs.debian.org, > > Package Salvaging Team > > > > Hi > > > > I'm interested in salvaging your package kbdd, in accordance with the > > Package Salvaging procedure outlined in the Developers Reference[1]. > > Your package meets the criteria for this process, and I would love to > > assist in preserving and maintaining it. As the Salvage process > > suggests, here is a list of the criteria that apply, in my opinion: > > > > - Bugs filed against the package do not have answers from the > > maintainer. > > - Upstream has released several versions, but despite there being > > a bug entry asking for it, it has not been packaged. > > - There are QA issues with the package. > > > > I've set up a repository within the salvage-team space[2] to assist you > > with this initial setup. If you decide not to accept the ITS, this > > repository can easily be moved to another location, such as debian/, or > > any place of your choosing. I hope this service helps make the > > transition to using a Git repository on Salsa smoother and more > > convenient for you. > > > > Your package was highlighted in the Bug of the Day[3] initiative, which > > aims to introduce newcomers to manageable tasks and guide them through > > the workflow to solve them. The focus of this initiative is on migrating > > packages to Salsa, as it's a great way to familiarize newcomers with a > > consistent Git-based workflow. > > > > Kind regards > > Andreas. > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > [2] https://salsa.debian.org/salvage-team/kbdd > > [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks > > > > > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), > > (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) > > Kernel taint flags: TAINT_WARN > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 > > -- > Stanislav Maslovski > -- https://fam-tille.de
Bug#1082187: If tls-on-connect is enabled, it makes no sense to complain that STARTTLS is not offered inside the (now-encrypted) session
Control: forwarded -1 https://github.com/jetmore/swaks/issues/104 Control: retitle -1 warn/err on conflicting tls-on-connect/tls options On 2024-09-20 Michael Deegan wrote: > Package: swaks > Version: 20201014.0-2 > Followup-For: Bug #1082187 > Ah, this is the result of forgetting that .swaksrc is a thing, which (in my > case) was attempting to be helpful by enabling --tls by default. Perhaps > swaks ought to do something sensible when both --tls and --tls-on-connect > are supplied... Hello, thanks for clearing this up, I have forwarded the issue upstream. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1082512: ITS: kbdd
Source: kbdd Version: 0.6-4 Severity: normal X-Debbugs-Cc: Stanislav Maslovski , 673...@bugs.debian.org, 836...@bugs.debian.org, 1079...@bugs.debian.org, Package Salvaging Team Hi I'm interested in salvaging your package kbdd, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - Bugs filed against the package do not have answers from the maintainer. - Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged. - There are QA issues with the package. I've set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/kbdd [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1082509: ITS: listadmin
Source: listadmin Version: 2.42-1.3 Severity: normal X-Debbugs-Cc: Noël Köthe , 652...@bugs.debian.org, 886...@bugs.debian.org, Package Salvaging Team Hi I'm interested in salvaging your package listadmin, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - NMUs, especially if there has been more than one NMU in a row. - Bugs filed against the package do not have answers from the maintainer. - Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged. - There are QA issues with the package. I've set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/listadmin [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#624626: puf doesn't urldecode filenames when writing them to disk
Control: severity -1 wishlist Thanks Hi, thank you for the bug report. I agree it would be nice if puf would decode download names. However, this is rather a feature request and thus I'm adjusting severity to wishlist. Kind regards Andreas. -- https://fam-tille.de
Bug#1075399: Status of psicode
Am Fri, Sep 20, 2024 at 10:43:29PM +0200 schrieb Michael Banck: > > There's a link to the github page in the top bar of the > > https://psicode.org website, it is at https://github.com/psi4/psi4/ > > Heh, I guess you meant the Debian source code - this one is at > https://salsa.debian.org/debichem-team/psicode... I'm looking at this one. > I pushed a fix for the FTBFS now,s Great. > but the testsuite is now broken due to > ancient perl and the package could need some updates in general... Yes. I personally would run `routine-update` on it to keep things simple. I'd be very happy if you could do so. In case you have time constraints I might have a look in case it would pop up next time as Bug of the Day candidate. Kind regards Andreas. -- https://fam-tille.de
Bug#1075399: Status of psicode
Hi, psicode showed up today as Bug of the Day[1] candidate. I checked the situation upstream[2] but I need to admit I do not have any clue about their versioning. They have a stable release of psi4 which is 1.9.1 (so we are lagging way behind with the Debian packaged 1.3.2) and than the web page also lists version numbers 3.8 - 3.12 which seems to be related to the supported Python version (unfortunately there is no 3.13 available.) However, I have no idea where to find the source code of psicode. I'm volunteering to help but I definitely need more information to do something sensible. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://psicode.org/installs/v191/ -- https://fam-tille.de
Bug#1082302: ITS: xmbmon
Source: xmbmon Severity: normal X-Debbugs-Cc: 472...@bugs.debian.org, 536...@bugs.debian.org, Lucas de Castro Borges , Package Salvaging Team Hi I'm interested in salvaging your package xmbmon, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I've set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/xmbmon [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1082187: If tls-on-connect is enabled, it makes no sense to complain that STARTTLS is not offered inside the (now-encrypted) session
On 2024-09-19 Michael Deegan wrote: > Package: swaks > Version: 20240103.0-1 > Severity: normal > eg. connecting to an SSMTPA on port 465: >swaks -a -tlsc --server submission.example.com --to mich...@example.com > Successfully connects on port 465, negotiates SSL, but then bombs out > complaining that STARTTLS is not advertised (names changed to protect the > innocent): [...] > I think --tls-on-connect should imply something similar to --tls-optional (I > would argue that advertising STARTTLS here would actually be a configuration > error). Hello, That behavior does not make sense, I cannot it reproduce though. :-( ametzler@argenau:~$ swaks -tlsc --server localhost --to ametz...@bebt.de -q rcpt === Trying localhost:465... === Connected to localhost. === TLS started with cipher TLSv1.3:TLS_AES_256_GCM_SHA384:256 === TLS client certificate not requested and not sent [...] === TLS peer certificate failed CA verification (self-signed certificate), passed host verification (using host localhost to verify) <~ 220 argenau.bebt.de ESMTP Exim 4.98 Thu, 19 Sep 2024 19:12:57 +0200 ~> EHLO argenau.bebt.de <~ 250-argenau.bebt.de Hello localhost [::1] <~ 250-SIZE 52428800 <~ 250-LIMITS MAILMAX=1000 RCPTMAX=5 <~ 250-8BITMIME <~ 250-PIPELINING <~ 250-PIPECONNECT <~ 250-AUTH CRAM-MD5 <~ 250-CHUNKING <~ 250-PRDR <~ 250 HELP ~> MAIL FROM: <~ 250 OK ~> RCPT TO: <~ 250 Accepted ~> QUIT <~ 221 argenau.bebt.de closing connection cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1082150: ITP: webext-vimium-firefox -- keyboard-based navigation and control (Firefox)
Package: wnpp Severity: wishlist Owner: Andreas Altergott X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: webext-vimium-firefox Version : 2.1.2 Upstream Contact: Phil Crosby * URL : https://vimium.github.io/ * License : MIT Programming Lang: JavaScript Description : keyboard-based navigation and control (Firefox) Vimium is a browser extension that provides keyboard-based navigation and control of the web in the spirit of the Vim editor. This package provides the Firefox version of the addon. - Why is this package useful/relevant? This extension allows one to use the Firefox web browser with Vim like navigation without the need of a mouse, which can be very comfortable for those used to Vim. - Is it a dependency for another package? No. - Do you use it? Yes. I love it. And it is actually one of the few packages I miss in Debian. - If there are other packages providing similar functionality, how does it compare? There are no other packages in debian which enhance the Firefox web browser with Vim like navigation. - How do you plan to maintain it? Inside a packaging team? I'd love to maintain it with the help of the the DebianWebextensionTeam (Mozilla WebExtension Packaging Team). - Are you looking for co-maintainers? No. But I don't mind it. Whatever fits the mozext-team best. - Do you need a sponsor? Yes.
Bug#1082038:
This should fix it: diff --git a/debian/rules b/debian/rules index b7441bc..11cddbf 100755 --- a/debian/rules +++ b/debian/rules @@ -26,6 +26,7 @@ configure-stamp: touch configure-stamp +build-arch: build build: build-stamp build-stamp: configure dh_testdir
Bug#1082038: quota: FTBFS with dpkg >= 1.22.7
Package: quota Severity: normal Version: 4.06-1.1 Dear Maintainer, quota fails to build with dpkg 1.22.7 or higher due to this change: dpkg (1.22.7) unstable; urgency=medium [ Guillem Jover ] * dpkg-buildpackage: Remove fallback handling for missing required targets. Previous dpkg-buildpackage invocations would issue a warning, and fallback to the build target: dpkg-buildpackage: warning: debian/rules must be updated to support the 'build-arch' and 'build-indep' targets (at least 'build-arch' seems to be missing) debian/rules build But since 1.22.7, the build fails if the build-arch target is not there: dh_clean debian/rules build-arch make: *** No rule to make target 'build-arch'. Stop. Related: https://wiki.debian.org/ReleaseGoals/BuildArchTarget The corresponding lintian tag: Tag: debian-rules-missing-required-target Severity: error Check: debian/rules Explanation: The debian/rules file does not provide all required targets. Both build-arch and build-indep must be provided even if they do nothing. . For sources that do not currently split the building of architecture dependent and independent installables, the following rules will fall back on the build target: . build-arch: build build-indep: build . Some say that the following form is recommended: . build: build-arch build-indep build-arch: build-stamp build-indep: build-stamp build-stamp: build here . As a modern alternative, you may wish to use the dh sequencer instead. Your sources will no longer be affected by this issue. . Policy now requires those targets. Please add them to avoid rejection. . In your next upload, please also close the bug from the mass bug filing you received. Details are described in the message to debian-devel cited below. See-Also: debian-policy 4.9, https://lists.debian.org/debian-devel/2021/11/msg00052.html
Bug#1031542: How to proceed with dbeacon?
Hi Ian (and Faidon), to answer Faidon's "That sounds fun!" first: Yes, its really fun. You will not beleave how many low hanging fruits are out there. Like in this case just apply a patch and have the bug fixed. Am Tue, Sep 17, 2024 at 03:51:20PM +0100 schrieb Iain R. Learmonth: > This software is used by ISPs to ensure that their multicast connectivity is > working. You might look at who maintains tools like BGP daemons or other > routing protocols for ideas about a future home. I need to admit that this is not my field of knowledge and I have no idea what BGP daemons are. May lazy way to deal with this is to leave it in Package Salvage team and wait until someone might catch up. In fact most of the packages should be handed over to QA maintenance. So if you do not have any more specific suggestions I'd prefer to leave it as is. > Thanks, Thank you both for your quick responses Andreas. -- https://fam-tille.de
Bug#986958: How to proceed with dbeacon?
Control: tags -1 pending
Thanks
Hi,
since bug #1031542 appeared today as Bug of the Day[1] candidate I
considered working on this package. First I realised that the old
Alioth team pkg-netmeasure does not exist on Salsa. Since I had no good
idea where to import it I simply used the Package Salvage team
repository[2]. From there we can move easily where ever you prefer.
I've modernised the packaging to recent standards (using routine-update)
and did some lintian cleanup. I also applied the patch for #1031542
(thus tagging pending here). I also tagged the bug
#986958 Updating the dbeacon Uploaders list
pending since I assume you can clarify what might be the best Uploader
for the package.
Just let me know what you think and I'll follow your recommendation
(regarding a sensible team and a sensible uploader.)
Kind regards
Andreas.
[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
[2] https://salsa.debian.org/salvage-team/dbeacon
--
https://fam-tille.de
Bug#1081996: RM: libcmrt -- ROM; unmaintained upstream, no users in Debian
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: libc...@packages.debian.org, Timo Aaltonen , Package Salvaging Team Control: affects -1 + src:libcmrt User: ftp.debian@packages.debian.org Usertags: remove Hi, I asked the maintainer of this package (in CC) whether libcmrt can be removed since its orphaned upstream and has no users in Debian. The answer was: Message-ID: <11e0b438-d4f8-42d5-9841-663de7dea...@debian.org> Yeah this should be removed, forgot that it even exists. So please remove this package from Debian. Thank you for working as ftpmaster Andreas.
Bug#840576: Can package libcmrt be removed?
Control: tags -1 moreinfo Thanks Hi, this package has over its time of existence maximum one vote for beeing used[1]. The upstream repository has been archived by the owner on Aug 5, 2022. It is now read-only.[2] A bug of this package has been proposed as Bug of the Week[3] and so the Package Salvage team is motivated on working on the package. However, it seems to be a sensible course of action to rather remove this package from Debian. I've tagged both open bugs to `moreinfo`. If the package might come up as Bug of the Day candidate again I will ask for removal of the package in case there this tag remains on the bugs. Kind regards Andreas. [1] https://qa.debian.org/popcon-graph.php?packages=libcmrt-dev&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 [2] https://github.com/intel/cmrt [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- https://fam-tille.de
Bug#1081235: gdebi: Migrate packaging repository to git?
On Tue, 10 Sep 2024 01:15:14 +0200 Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?= wrote: > "Proof of concept" available at > > https://salsa.debian.org/gusnan/gdebi > > I haven't imported my last NMU (10), since it was uploaded with a delay > and hasn't hit the archives yet, but will of course do when and if it > does. > > /Andreas > gus...@debian.org > > So, now it hit the archives, and the git repository has been updated. Please check it out. best /Andreas Rönnquist gus...@debian.org
Bug#1069502: [Help] Re: input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
Hi Jeremy,
Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> Try this patch.
Works.
Thanks a lot for the quick help
Andreas.
--
https://fam-tille.de
Bug#1075545: Fwd: sumaclust: Fails to build from source with GCC-14
Control: forwarded -1 Céline Mercier
Control: tags -1 upstream
Thanks
Hi Céline,
the Debian packaged sumaclust fails to build from source when trying to
build with GCC 14. It would be great if you could fix the errors
mentioned below.
Kind regards
Andreas.
- Weitergeleitete Nachricht von Matthias Klose -
Date: Wed, 03 Jul 2024 12:45:09 +
From: Matthias Klose
To: mainto...@bugs.debian.org
Subject: sumaclust: ftbfs with GCC-14
Package: src:sumaclust
Version: 1.0.36+ds-2
Severity: important
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14
[This bug is targeted to the upcoming trixie release]
Please keep this issue open in the bug tracker for the package it
was filed for. If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.
The package fails to build in a test rebuild on at least amd64 with
gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
severity of this report will be raised before the trixie release.
The full build log can be found at:
http://qa-logs.debian.net/2024/07/01/sumaclust_1.0.36+ds-2_unstable_gccexp.log
The last lines of the build log are at the end of this report.
To build with GCC 14, either set CC=gcc-14 CXX=g++-14 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.
apt-get -t=experimental install g++
Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-14/porting_to.html
[...]
make[1]: *** Waiting for unfinished jobs
sumaclust.c: In function ‘printInBIOMformat’:
sumaclust.c:294:27: error: assignment to ‘struct **’ from
incompatible pointer type ‘struct fastaSeqPtr *’ [-Wincompatible-pointer-types]
294 | c = (*seq)->center;
| ^
sumaclust.c: In function ‘printInOTUtableFormat’:
sumaclust.c:461:27: error: assignment to ‘struct **’ from
incompatible pointer type ‘struct fastaSeqPtr *’ [-Wincompatible-pointer-types]
461 | c = (*seq)->center;
| ^
sumaclust.c: In function ‘putSeqInCluster’:
sumaclust.c:583:24: error: assignment to ‘struct fastaSeqPtr *’ from
incompatible pointer type ‘struct **’ [-Wincompatible-pointer-types]
583 | (*seq)->center = center;
|^
sumaclust.c: In function ‘computeClusterWeights’:
sumaclust.c:750:24: error: assignment to ‘struct **’ from
incompatible pointer type ‘struct fastaSeqPtr *’ [-Wincompatible-pointer-types]
750 | center = (*seq)->center;
|^
sumaclust.c:763:24: error: assignment to ‘struct **’ from
incompatible pointer type ‘struct fastaSeqPtr *’ [-Wincompatible-pointer-types]
763 | center = (*seq)->center;
|^
sumaclust.c: In function ‘main’:
sumaclust.c:1001:42: error: assignment to ‘struct fastaSeqPtr *’ from
incompatible pointer type ‘fastaSeqPtr’ {aka ‘struct *’}
[-Wincompatible-pointer-types]
1001 | ((db.fastaSeqs)+i)->next = (db.fastaSeqs)+i-1;
| ^
sumaclust.c:1009:73: error: passing argument 4 of ‘qsort’ from incompatible
pointer type [-Wincompatible-pointer-types]
1009 | qsort((void*) uniqSeqs, n, sizeof(fastaSeqPtr),
sortSeqsWithCounts);
|
^~
|
|
|
int (*)(const void **, const void **)
In file included from sumaclust.c:9:
/usr/include/stdlib.h:971:34: note: expected ‘__compar_fn_t’ {aka ‘int
(*)(const void *, const void *)’} but argument is of type ‘int (*)(const void
**, const void **)’
971 |__compar_fn_t __compar) __nonnull ((1, 4));
|~~^~~~
sumaclust.c:1011:73: error: passing argument 4 of ‘qsort’ from incompatible
pointer type [-Wincompatible-pointer-types]
1011 | qsort((void*) uniqSeqs, n, sizeof(fastaSeqPtr),
reverseSortSeqsWithCounts);
|
^
|
|
|
int (*)(const void **, const void **)
/usr/include/stdlib.h:971:34: note: expected ‘__compar_fn_t’ {aka ‘int
(*)(const void *, const void *)’} but argument is of type ‘int (*)(const void
**, con
Bug#1069502: [Help] Re:input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
Control: tags -1 help Control: tags -1 confirmed Thanks Hi, since input-utils showed up as Bug of the Day[1] I worked down the list of bugs including upgrading to latest upstream. Unfortunately the FTBFS for several 32bit architectures (not only armhf) remains[2]. Since I have no experience with these architectures I'd kindly ask for help here. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://buildd.debian.org/status/package.php?p=input-utils -- https://fam-tille.de
Bug#1079007: src:nvidia-nccl: fails to migrate to testing for too long: missing uploads for arm64 and ppc64el
On 8/19/24 03:36, Andreas Beckmann wrote: On 18/08/2024 21.24, Paul Gevers wrote: arm64 FTBFS with /usr/include/aarch64-linux-gnu/bits/math-vector.h(96): error: identifier "__Float32x4_t" is undefined typedef __Float32x4_t __f32x4_t; not a regression in nvidia-nccl, the version in testing nowadays ftbfs similarily Andreas
Bug#995951: Forwarded upstream / tags pending
Control: forwarded -1 https://github.com/keesL/metar/issues/20 Control: tags -1 upstream Control: tags -1 pending Thanks Hi, I moved the packaging to Debian Science team and added a patch[1] to the repository. I plan to upload the package to DELAYED=10. Kind regards Andreas. [1] https://salsa.debian.org/science-team/metar/-/blob/master/debian/patches/fix_url_to_icao_stations.patch?ref_type=heads -- https://fam-tille.de
Bug#723138: Taking over metar into Debian Science team
Hi Joost, thank you for the quick response. Am Sun, Sep 15, 2024 at 08:13:00AM +0200 schrieb Joost van Baal-Ilić: > Your assumption is correct, you are very welcome to move metar git/maintenance > to the debian science umbrella. Thanks for confirming. I've prepared an upload[3] fixing some bugs and opened some issues in upstream Git to sort out whether we can close the other Debian bugs. Kind regards Andreas. [3] https://salsa.debian.org/science-team/metar > On Sun, Sep 15, 2024 at 07:54:02AM +0200, Andreas Tille wrote: > > Hi, > > > > metar showed up as Bug of the Day[1] and I'd like to work on the bugs of > > the package. I think its a nice fit to Debian Science team. Usually I > > would file some ITS bug following the Package Salvage procedure[2] but > > given that you asked for sponsoring (RFS) I assume you would like to > > join a team where its easy to find sponsors which fits for the Debian > > Science team. > > > > So I simply assume that this is fine for you. > > > > Kind regards > > Andreas. > > > > [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks > > [2] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > > > -- > > https://fam-tille.de > > > -- https://fam-tille.de
Bug#641133: Forwarded upstream
Control: forwarded -1 https://github.com/keesL/metar/issues/19 Control: tags -1 upstream
Bug#510359: Forwarded upstream
Control: forwarded -1 https://github.com/keesL/metar/issues/18 Control: tags -1 upstream
Bug#490888: Forwarded upstream
Control: forwarded -1 https://github.com/keesL/metar/issues/17 Control: tags -1 upstream
Bug#723138: Taking over metar into Debian Science team
Hi, metar showed up as Bug of the Day[1] and I'd like to work on the bugs of the package. I think its a nice fit to Debian Science team. Usually I would file some ITS bug following the Package Salvage procedure[2] but given that you asked for sponsoring (RFS) I assume you would like to join a team where its easy to find sponsors which fits for the Debian Science team. So I simply assume that this is fine for you. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging -- https://fam-tille.de
Bug#1081807: FTFBS: multiple definition of `get_max_fds'
Package: gnupg2 Version: 2.4.5-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) No idea what broke here: i686-w64-mingw32-gcc -I/usr/i686-w64-mingw32/include -I/usr/i686-w64-mingw32/in clude -I/usr/i686-w64-mingw32/include -I/usr/i686-w64-mingw32/include -Wall -Wno -format-zero-length -Wno-pointer-sign -Wpointer-arith -g -Os -Xlinker --no-inse rt-timestamp -static -o gpgv.exe gpgv.o build-packet.o compress.o free-packet.o getkey.o expand-group.o call-keyboxd.o keydb.o keyring.o seskey.o kbnode.o main proc.o armor.o mdfilter.o textfilter.o progress.o misc.o rmd160.o openfile.o key id.o parse-packet.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o objcache.o ecdh.o verify.o ../kbx/libkeybox.a ../common/libcommonpth.a ../regexp/libregexp. a ../common/libgpgrl.a -lz -L/usr/i686-w64-mingw32/lib -lgcrypt -L/usr/i686-w6 4-mingw32/lib -lassuan -L/usr/i686-w64-mingw32/lib -lnpth -L/usr/i686-w64-mingw3 2/lib -lgpg-error -lws2_32 gpgv-w32info.o /usr/bin/i686-w64-mingw32-ld: /usr/i686-w64-mingw32/lib/libgpg-error.a(libgpg_er ror_la-spawn-w32.o): in function `get_max_fds': ./build-i686-w64-mingw32/src/../../src/spawn-w32.c:111: multiple definition of ` get_max_fds'; ../common/libcommonpth.a(libcommonpth_a-exechelp-w32.o):/tmp/GNUPG2/gnupg2/build-gpgv-win32/common/../../common/exechelp-w32.c:120: first defined here collect2: error: ld returned 1 exit status I do not think the presence/absence of get_max_fds in /usr/i686-w64-mingw32/lib/libgpg-error.a has changed recently. This does not show up on 2.2. cu Andreas
Bug#1081771: ITS: portsentry
Source: portsentry
Version: 1.2-14
Severity: normal
X-Debbugs-Cc: 894...@bugs.debian.org, 1028...@bugs.debian.org, Dario Minnucci
, Package Salvaging Team
Hi
I'm interested in salvaging your package, portsentry, in accordance with
the Package Salvaging procedure outlined in the Developers Reference[1].
Your package meets the criteria for this process, and I would love to
assist in preserving and maintaining it. As the Salvage process
suggests, here is a list of the criteria that apply, in my opinion:
- NMUs, especially if there has been more than one NMU in a row.
- Bugs filed against the package do not have answers from the
maintainer.
- There are QA issues with the package.
The package was in collab-maint on Alioth and migrated into Debian
team[2] by Jelmer Vernooij. If you choose not to accept the ITS, I’d be
more than happy to help you move it to another location than debian/.
My goal is to make it as easy as possible for you to make use of the
Salsa repository.
Your package was highlighted in the Bug of the Day[3] initiative, which
aims to introduce newcomers to manageable tasks and guide them through
the workflow to solve them. The focus of this initiative is on migrating
packages to Salsa, as it's a great way to familiarize newcomers with a
consistent Git-based workflow.
Kind regards
Andreas.
[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://salsa.debian.org/debian/portsentry
[3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1081770: ITS: nullidentd
Source: nullidentd Version: 1.0-5 Severity: normal X-Debbugs-Cc: 709...@bugs.debian.org, 833...@bugs.debian.org, 872...@bugs.debian.org, 1075...@bugs.debian.org, Jeroen Schot , Package Salvaging Team Hi I'm interested in salvaging your package, nullidentd, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - NMUs, especially if there has been more than one NMU in a row. - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I've set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/nullidentd [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#573098: Bug#863485: cal uploaded to DELAYED=10
Dear Javier, Am Fri, Sep 13, 2024 at 12:34:19AM +0200 schrieb Javier Fernandez-Sanguino: > Dear Andreas, > > Thank you for taking care of this upload and for fixing the outstanding > bugs. You are welcome. > If you wish, you can push directly to unstable. There is no need to use > DELAYED queue. Upload done to unstable. Saludos Andreas. > Best regards > > Javier > Saludos, > > Javier > > El jue, 12 sept 2024, 22:21, Andreas Tille escribió: > > > Control: tags -1 pending > > Thanks > > > > Hi Javier, > > > > as per the ITS bug the package was imported to salvage team repository[1] > > and is uploaded now to DELAYED=10. > > > > Kind regards > > Andreas. > > > > [1] https://salsa.debian.org/salvage-team/cal > > > > -- > > https://fam-tille.de > > -- https://fam-tille.de
Bug#953053: psychopy: missing python3 dependencies
Adding Yaroslav to the discussion since he is the expert. Kind regards, Andreas. Am Thu, Sep 12, 2024 at 10:29:56PM +0200 schrieb Étienne Mollier: > Hi, > > I was having a look at eventually bumping psychopy to v2024. It > seems that dh-python3 helpfully reports dependencies declared by > upstream but missing from Debian: > > I: dh_python3 pydist:302: Cannot find package that provides > imageio_ffmpeg. > Please add package that provides it to Build-Depends > or add "imageio_ffmpeg python3-imageio-ffmpeg" line to > debian/py3dist-overrides > or add proper dependency to Depends by hand and ignore this info. > I: dh_python3 pydist:302: Cannot find package that provides > psychtoolbox. ... > I: dh_python3 pydist:302: Cannot find package that provides > javascripthon. ... > I: dh_python3 pydist:302: Cannot find package that provides > pypi_search. ... > I: dh_python3 pydist:302: Cannot find package that provides esprima. ... > I: dh_python3 pydist:302: Cannot find package that provides ffpyplayer. > ... > I: dh_python3 pydist:302: Cannot find package that provides > opencv_python. ... > > imageio_ffmpeg upstream looks located here: > https://github.com/imageio/imageio-ffmpeg > > psychtoolbox from pypi.org leads to confusing source code: > https://pypi.org/project/psychtoolbox/ > > javascripthon looks non-trivial: > https://github.com/metapensiero/metapensiero.pj > > pypi_search upstream archived their repository: > https://github.com/asadmoosvi/pypi-search > > esprima is already recorded work needed and prospective package: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987923 > > ffpyplayer seems located here: > https://github.com/matham/ffpyplayer > > opencv_python stems from here, but is also confusing: > https://github.com/opencv/opencv-python > > Something is bugging me: is the package usable at all with these > missing components? When trying to put back the test suite on > tracks, each item ends up in error, mainly because of missing > the esprima module (and the rest chokes on pyglet.gl being used > as regular GL while missing a number of its attributes). > > I'm sorry it may be a bit overwhelming. I hope targets painting > will help with putting back the package into good shape in the > end though. > > Have a nice day, :) > -- > .''`. Étienne Mollier > : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > `. `' sent from /dev/pts/4, please excuse my verbosity >`- -- https://fam-tille.de
Bug#900121: rep-gtk uploaded to DELAYED=10
Hi Jose, thanks for confirming. I've just uploaded rep-gtk to unstable. Kind regards Andreas. Am Thu, Sep 12, 2024 at 12:58:41AM +0100 schrieb Jose M Calhariz: > 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 -- https://fam-tille.de
Bug#508558: Add sloc2html to sloccount package
Control: tags -1 pending
Control: tags -1 - moreinfo
Thanks
Hi,
I've pushed this version to Git. I think the easiest strategy is to
wait until sloccount in deferred queue has hit unstable (in three days)
and than upload your fix directly to unstable in another version.
Thanks a lot for your contribution
Andreas.
PS: Feel free to ping me in four days to make sure I will not forget to
upload
https://salsa.debian.org/salvage-team/sloccount/-/commit/b3aed630bc818c764e650b72a778452ca8a3911d
Am Tue, Sep 10, 2024 at 01:02:10PM +0200 schrieb Elie De Brauwer:
> Hi Andreas,
>
> Please find attached a revised version of 'sloc2html.py'. Some issues were
> addressed and it's in full Python 3 now.
>
>
> Kind regards
> E.
>
> On Sat, Sep 7, 2024 at 2:20 PM Andreas Tille wrote:
>
> > Control: tags -1 moreinfo
> > Thanks
> >
> > Hi,
> >
> > since package sloccount came up in the Bug of the Day[1] we tried to
> > salvage this packege[2]. I followed your hint to add sloc2html in
> > Git[3]. I've used 2to3 to convert the script to Python3. Unfortunately
> > it does not work. If you can fix the script I'd happily add it to the
> > package but for the moment I do not see any advantage for our users.
> >
> > Kind regards
> > Andreas.
> >
> > [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> > [2] https://bugs.debian.org/1078785
> > [3]
> > https://salsa.debian.org/salvage-team/sloccount/-/tree/master/debian/sloc2html?ref_type=heads
> >
> > --
> > https://fam-tille.de
> >
> >
>
> --
> Elie De Brauwer
> #!/usr/bin/env python
> """
> Written by Rasmus Toftdahl Olesen
> Modified slightly by David A. Wheeler and Elie De Brauwer.
> Brought into the year 2024 by Elie De Brauwer
> Released under the GNU General Public License v. 2 or higher
> """
>
> import sys
>
> NAME = "sloc2html"
> VERSION = "0.0.3"
>
> if len(sys.argv) != 2:
> print("Usage:")
> print("\t" + sys.argv[0] + " ")
> print("\nThe output of sloccount should be with --wide and --multiproject
> formatting")
> sys.exit()
>
> colors = { "python" : "blue",
>"ansic" : "yellow",
>"perl" : "purple",
>"cpp" : "green",
>"sh" : "red",
>"yacc" : "brown",
>"lex" : "silver",
># Feel free to make more specific colors.
>"ruby" : "maroon",
>"cs" : "gray",
>"java" : "navy",
>"javascript" : "navy",
>"ada" : "olive",
>"lisp" : "fuchsia",
>"objc" : "purple",
>"fortran" : "purple",
>"cobol" : "purple",
>"pascal" : "purple",
>"asm" : "purple",
>"csh" : "purple",
>"tcl" : "purple",
>"exp" : "purple",
>"awk" : "purple",
>"sed" : "purple",
>"makefile" : "purple",
>"sql" : "purple",
>"php" : "purple",
>"modula3" : "purple",
>"ml" : "purple",
>"haskell" : "purple",
>"vhdl" : "purple",
>"xml" : "purple"
> }
>
>
> print("")
> print("")
> print("Counted Source Lines of Code (SLOC)")
> print("")
> print("")
> print("Counted Source Lines of Code")
>
> with open(sys.argv[1], "r", encoding="utf-8") as file:
>
> print("Projects")
> line = ""
> while line != "SLOC\tDirectory\tSLOC-by-Language (Sorted)\n":
> line = file.readline()
>
> print("")
> print("LinesProjectLanguage
> distribution")
> line = file.readline()
> while line != "\n":
> num, project, langs = line.split()
> print("" + num + "" + project + "
Bug#1081646: trickle: FTBFS with 64-bit time_t on 32-bit platforms
Source: trickle
Version: 1.08+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
trickle FTBFS with 64-bit time_t on 32-bit platforms (e.g. armel, armhf,
but not i386 (keeps its 32-bit time_t):
...
gcc -DHAVE_CONFIG_H -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Icompat
-I/usr/include/tirpc -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/build/trickle-1.08+ds=. -fstack-protect
or-strong -fstack-clash-protection -Wformat -Werror=format-security -c -o xdr.o
xdr.c
xdr.c: In function 'xdr_msg_delayinfo':
xdr.c:64:26: error: passing argument 2 of 'xdr_long' from incompatible pointer
type [-Wincompatible-pointer-types]
64 | X(xdr_long(xdrs, &delayinfo->delaytv.tv_sec));
| ^~
| |
| __time64_t * {aka long long int *}
xdr.c:15:14: note: in definition of macro 'X'
15 | if (!x) \
| ^
In file included from /usr/include/tirpc/rpc/rpc.h:43,
from xdr.c:10:
/usr/include/tirpc/rpc/xdr.h:291:33: note: expected 'long int *' but argument
is of type '__time64_t *' {aka 'long long int *'}
291 | extern bool_t xdr_long(XDR *, long *);
| ^~
xdr.c:65:26: error: passing argument 2 of 'xdr_long' from incompatible pointer
type [-Wincompatible-pointer-types]
65 | X(xdr_long(xdrs, &delayinfo->delaytv.tv_usec));
| ^~~
| |
| __suseconds64_t * {aka long long int *}
xdr.c:15:14: note: in definition of macro 'X'
15 | if (!x) \
| ^
/usr/include/tirpc/rpc/xdr.h:291:33: note: expected 'long int *' but argument
is of type '__suseconds64_t *' {aka 'long long int *'}
291 | extern bool_t xdr_long(XDR *, long *);
| ^~
...
AFAIK there is no xdr_long_long()
Andreas
Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
On 9/13/24 10:12, Wolfgang Schnitker via pkg-nvidia-devel wrote: please don't forget to apply this bpo path also to nvidia-tesla-470 driver package because this is still a part of the bookworm series. good point ;-) Andreas
Bug#1031907: cal uploaded to DELAYED=10
Control: tags -1 pending Thanks Hi Javier, as per the ITS bug the package was imported to salvage team repository[1] and is uploaded now to DELAYED=10. Kind regards Andreas. [1] https://salsa.debian.org/salvage-team/cal -- https://fam-tille.de
Bug#1081379: vhba-dkms: module fails to build with gcc-14 due to -Werror=incompatible-pointer-types
Followup-For: Bug #1081379 I'm attaching a few patches to simplify the packaging and bring dkms integration in line with all the other *-dkms packages in the archive. There is no attempt to fix the gcc-14 issue. Thanks for considering. Andreas PS: is the package available in some VCS? >From 9b0f9227970305061520c04ac676c5b766f53736 Mon Sep 17 00:00:00 2001 From: Andreas Beckmann Date: Wed, 11 Sep 2024 17:22:06 +0200 Subject: [PATCH 1/6] simplify appstream metadata installation --- debian/changelog | 6 ++ debian/rules | 3 --- debian/vhba-dkms.install | 1 + 3 files changed, 7 insertions(+), 3 deletions(-) create mode 100644 debian/vhba-dkms.install diff --git a/debian/changelog b/debian/changelog index 695e510..f2191eb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +vhba-module (20240202-6) UNRELEASED; urgency=medium + + * Simplify appstream metadata installation. + + -- Andreas Beckmann Wed, 11 Sep 2024 17:20:37 +0200 + vhba-module (20240202-5) unstable; urgency=medium * debian/appstream/net.sf.cdemu.vhba_module.metainfo.xml: diff --git a/debian/rules b/debian/rules index 451466b..f0a7b47 100755 --- a/debian/rules +++ b/debian/rules @@ -25,9 +25,6 @@ override_dh_auto_install: install -d$(DESTDIR) install -m 644 -D $(CURDIR)/Makefile $(DESTDIR)/ install -m 644 -D $(CURDIR)/*.c $(DESTDIR)/ - mkdir -p $(PKGDIR)/usr/share/metainfo - cp -f $(CURDIR)/debian/appstream/net.sf.cdemu.vhba_module.metainfo.xml $(PKGDIR)/usr/share/metainfo - chmod 644 $(PKGDIR)/usr/share/metainfo/net.sf.cdemu.vhba_module.metainfo.xml override_dh_dkms: dh_dkms -V diff --git a/debian/vhba-dkms.install b/debian/vhba-dkms.install new file mode 100644 index 000..c9840b2 --- /dev/null +++ b/debian/vhba-dkms.install @@ -0,0 +1 @@ +debian/appstream/net.sf.cdemu.vhba_module.metainfo.xml usr/share/metainfo/ -- 2.39.2 >From 0fa73d76407a2cf31eeacbbc5800d3f04e77eaba Mon Sep 17 00:00:00 2001 From: Andreas Beckmann Date: Wed, 11 Sep 2024 17:23:45 +0200 Subject: [PATCH 2/6] simplify dkms installation --- debian/changelog | 1 + debian/rules | 14 +++--- 2 files changed, 4 insertions(+), 11 deletions(-) diff --git a/debian/changelog b/debian/changelog index f2191eb..3d8470c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,7 @@ vhba-module (20240202-6) UNRELEASED; urgency=medium * Simplify appstream metadata installation. + * Simplify dkms installation. -- Andreas Beckmann Wed, 11 Sep 2024 17:20:37 +0200 diff --git a/debian/rules b/debian/rules index f0a7b47..b5777ba 100755 --- a/debian/rules +++ b/debian/rules @@ -1,17 +1,12 @@ #!/usr/bin/make -f # -*- makefile -*- - #export DH_VERBOSE=1 -# Get package version info. -SOURCE_VERSION := $(shell head -1 debian/changelog | cut -d\( -f2 | cut -d\) -f1) -UPSTREAM_VERSION := $(shell echo "$(SOURCE_VERSION)" | cut -d- -f1) - -# Installation directories -PKGDIR := $(CURDIR)/debian/vhba-dkms -DESTDIR := $(PKGDIR)/usr/src/vhba-$(UPSTREAM_VERSION) +include /usr/share/dpkg/pkg-info.mk +execute_after_dh_install: + dh_install -pvhba-dkms Makefile *.c usr/src/vhba-$(DEB_VERSION_UPSTREAM)/ override_dh_auto_configure: @@ -22,9 +17,6 @@ override_dh_auto_test: override_dh_auto_clean: override_dh_auto_install: - install -d$(DESTDIR) - install -m 644 -D $(CURDIR)/Makefile $(DESTDIR)/ - install -m 644 -D $(CURDIR)/*.c $(DESTDIR)/ override_dh_dkms: dh_dkms -V -- 2.39.2 >From a1265153c3f8bb8efe20f4f6bc08c6cbd9ff1b9b Mon Sep 17 00:00:00 2001 From: Andreas Beckmann Date: Wed, 11 Sep 2024 17:25:39 +0200 Subject: [PATCH 3/6] switch to dh-sequence-dkms --- debian/changelog | 1 + debian/control| 3 +-- debian/rules | 5 + debian/vhba-dkms.dkms | 2 -- debian/vhba-dkms.postinst | 2 +- 5 files changed, 4 insertions(+), 9 deletions(-) diff --git a/debian/changelog b/debian/changelog index 3d8470c..d517d29 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ vhba-module (20240202-6) UNRELEASED; urgency=medium * Simplify appstream metadata installation. * Simplify dkms installation. + * Switch to dh-sequence-dkms. -- Andreas Beckmann Wed, 11 Sep 2024 17:20:37 +0200 diff --git a/debian/control b/debian/control index 76b39b8..0740329 100644 --- a/debian/control +++ b/debian/control @@ -4,8 +4,7 @@ Priority: optional Homepage: https://cdemu.sourceforge.io/ Maintainer: Matteo Bini Build-Depends: debhelper-compat (= 13), - dh-dkms, - dkms + dh-sequence-dkms, Standards-Version: 4.7.0 Rules-Requires-Root: no diff --git a/debian/rules b/debian/rules index b5777ba..d4e63b7 100755 --- a/debian/rules +++ b/deb
Bug#1081379: vhba-dkms: module fails to build with gcc-14 due to -Werror=incompatible-pointer-types
Package: vhba-dkms Version: 20240202-5 Severity: important Hi, vhba-dkms fails to build a module for Linux 6.11 in experimental. I haven't looked in detail, but this is probably caused by the switch from gcc-13 to gcc-14 (and not a kernel interface change). gcc-14 enabled -Werror=incompatible-pointer-types etc. by default. DKMS make.log for vhba-20240202 for kernel 6.11-rc5-rt-amd64 (x86_64) Wed Sep 11 08:39:38 UTC 2024 make -C /lib/modules/6.11-rc5-rt-amd64/build M=/var/lib/dkms/vhba/20240202/build modules make[1]: Entering directory '/usr/src/linux-headers-6.11-rc5-rt-amd64' CC [M] /var/lib/dkms/vhba/20240202/build/vhba.o /var/lib/dkms/vhba/20240202/build/vhba.c:1087:15: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types] 1087 | .remove = vhba_remove, | ^~~ /var/lib/dkms/vhba/20240202/build/vhba.c:1087:15: note: (near initialization for 'vhba_platform_driver..remove') make[3]: *** [/usr/src/linux-headers-6.11-rc5-common-rt/scripts/Makefile.build:249: /var/lib/dkms/vhba/20240202/build/vhba.o] Error 1 make[2]: *** [/usr/src/linux-headers-6.11-rc5-common-rt/Makefile:1950: /var/lib/dkms/vhba/20240202/build] Error 2 make[1]: *** [/usr/src/linux-headers-6.11-rc5-common-rt/Makefile:236: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.11-rc5-rt-amd64' make: *** [Makefile:14: modules] Error 2 Andreas
Bug#1081377: iptables-netflow-dkms: module fails to build with gcc-14 due to -Werror=incompatible-pointer-types
tialization of 'int (*)(const struct ctl_table *, int, void *, size_t *,
loff_t *)' {aka 'int (*)(const struct ctl_table *, int, void *, long unsigned
int *, long long int *)'} from incompatible pointer type 'int (*)(struct
ctl_table *, int, void *, size_t *, loff_t *)' {aka 'int (*)(struct ctl_table
*, int, void *, long unsigned int *, long long int *)'}
[-Wincompatible-pointer-types]
1879 | .proc_handler = &sampler_procctl,
| ^
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1879:35: note: (near
initialization for 'netflow_sysctl_table[12].proc_handler')
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1897:35: error:
initialization of 'int (*)(const struct ctl_table *, int, void *, size_t *,
loff_t *)' {aka 'int (*)(const struct ctl_table *, int, void *, long unsigned
int *, long long int *)'} from incompatible pointer type 'int (*)(struct
ctl_table *, int, void *, size_t *, loff_t *)' {aka 'int (*)(struct ctl_table
*, int, void *, long unsigned int *, long long int *)'}
[-Wincompatible-pointer-types]
1897 | .proc_handler = &snmp_procctl,
| ^
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1897:35: note: (near
initialization for 'netflow_sysctl_table[14].proc_handler')
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1905:35: error:
initialization of 'int (*)(const struct ctl_table *, int, void *, size_t *,
loff_t *)' {aka 'int (*)(const struct ctl_table *, int, void *, long unsigned
int *, long long int *)'} from incompatible pointer type 'int (*)(struct
ctl_table *, int, void *, size_t *, loff_t *)' {aka 'int (*)(struct ctl_table
*, int, void *, long unsigned int *, long long int *)'}
[-Wincompatible-pointer-types]
1905 | .proc_handler = &natevents_procctl,
| ^
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1905:35: note: (near
initialization for 'netflow_sysctl_table[15].proc_handler')
make[3]: ***
[/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:249:
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.o] Error 1
make[2]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:1950:
/var/lib/dkms/ipt-netflow/2.6/build] Error 2
make[1]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:236: __sub-make]
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.11-rc5-amd64'
make: *** [Makefile:27: ipt_NETFLOW.ko] Error 2
Andreas
Bug#1081375: lttng-modules-dkms: module fails to build for Linux 6.11: error: conflicting types for 'trace_kfree_skb'
ntext-vsuid.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-vgid.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-vegid.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-vsgid.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-interruptible.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-need-reschedule.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-calibrate.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-hostname.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-context-callstack.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/probes/lttng.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-tracker-id.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-bytecode.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-bytecode-interpreter.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-bytecode-specialize.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-bytecode-validator.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/probes/lttng-probe-user.o CC [M] /var/lib/dkms/lttng-modules/2.13.14/build/src/lttng-tp-mempool.o make[3]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:490: /var/lib/dkms/lttng-modules/2.13.14/build/src/probes] Error 2 make[3]: *** Waiting for unfinished jobs make[2]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:490: /var/lib/dkms/lttng-modules/2.13.14/build/src] Error 2 make[1]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:1950: /var/lib/dkms/lttng-modules/2.13.14/build] Error 2 make: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:236: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-6.11-rc5-amd64' Andreas
Bug#1081372: dahdi-dkms: module fails to build with gcc-14: error: initialization of 'int (*)(struct device *, const struct device_driver *)' from incompatible pointer type
d/drivers/dahdi/wctdm24xxp/wctdm24xxp.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wcte12xp/base.o LD [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wcte12xp/wcte12xp.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/voicebus/voicebus.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/voicebus/GpakCust.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/voicebus/GpakApi.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/voicebus/voicebus_net.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/voicebus/vpmoct.o LD [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/voicebus/dahdi_voicebus.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wcb4xxp/base.o LD [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wcb4xxp/wcb4xxp.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-core.o CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.o /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:469:18: error: initialization of 'int (*)(struct device *, const struct device_driver *)' from incompatible pointer type 'int (*)(struct device *, struct device_driver *)' [-Wincompatible-pointer-types] 469 | .match = astribank_match, | ^~~ /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:469:18: note: (near initialization for 'toplevel_bus_type.match') /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:825:18: error: initialization of 'int (*)(struct device *, const struct device_driver *)' from incompatible pointer type 'int (*)(struct device *, struct device_driver *)' [-Wincompatible-pointer-types] 825 | .match = xpd_match, | ^ /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:825:18: note: (near initialization for 'xpd_type.match') make[4]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:249: /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:490: /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp] Error 2 make[2]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:1950: /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi] Error 2 make[1]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:236: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.11-rc5-amd64' make: *** [Makefile:74: modules] Error 2 make -C /lib/modules/6.11-rc5-amd64/build KBUILD_EXTMOD=/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi DAHDI_INCLUDE=/var/lib/dkms/dahdi/3.1.0+git20230717/build/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m make[1]: Entering directory '/usr/src/linux-headers-6.11-rc5-amd64' CC [M] /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.o /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:469:18: error: initialization of 'int (*)(struct device *, const struct device_driver *)' from incompatible pointer type 'int (*)(struct device *, struct device_driver *)' [-Wincompatible-pointer-types] 469 | .match = astribank_match, | ^~~ /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:469:18: note: (near initialization for 'toplevel_bus_type.match') /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:825:18: error: initialization of 'int (*)(struct device *, const struct device_driver *)' from incompatible pointer type 'int (*)(struct device *, struct device_driver *)' [-Wincompatible-pointer-types] 825 | .match = xpd_match, | ^ /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.c:825:18: note: (near initialization for 'xpd_type.match') make[4]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:249: /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/xbus-sysfs.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:490: /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp] Error 2 make[2]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:1950: /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi] Error 2 make[1]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:236: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.11-rc5-amd64' make: *** [Makefile:74: modules] Error 2 Andreas
Bug#1081370: apfs-dkms: module fails to build for Linux 6.11: error: implicit declaration of function 'page_mkclean'
Package: apfs-dkms Version: 0.3.10-1 Severity: important apfs-dkms fails to build a module for Linux 6.11 in experimental: DKMS make.log for linux-apfs-rw-0.3.10 for kernel 6.11-rc5-amd64 (x86_64) Wed Sep 11 07:40:14 UTC 2024 make: Entering directory '/usr/src/linux-headers-6.11-rc5-amd64' CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/btree.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/compress.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/dir.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/extents.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/file.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/inode.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/key.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/libzbitmap.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/lzfse/lzfse_decode.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/lzfse/lzfse_decode_base.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/lzfse/lzfse_fse.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/lzfse/lzvn_decode_base.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/message.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/namei.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/node.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/object.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/snapshot.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/spaceman.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/super.o /var/lib/dkms/linux-apfs-rw/0.3.10/build/extents.c:11:9: warning: "MAX" redefined 11 | #define MAX(X, Y) ((X) <= (Y) ? (Y) : (X)) | ^~~ In file included from /usr/src/linux-headers-6.11-rc5-common/include/linux/kernel.h:28, from /usr/src/linux-headers-6.11-rc5-common/include/linux/cpumask.h:11, from /usr/src/linux-headers-6.11-rc5-common/arch/x86/include/asm/paravirt.h:21, from /usr/src/linux-headers-6.11-rc5-common/arch/x86/include/asm/irqflags.h:80, from /usr/src/linux-headers-6.11-rc5-common/include/linux/irqflags.h:18, from /usr/src/linux-headers-6.11-rc5-common/include/linux/spinlock.h:59, from /usr/src/linux-headers-6.11-rc5-common/include/linux/wait.h:9, from /usr/src/linux-headers-6.11-rc5-common/include/linux/wait_bit.h:8, from /usr/src/linux-headers-6.11-rc5-common/include/linux/fs.h:6, from /usr/src/linux-headers-6.11-rc5-common/include/linux/highmem.h:5, from /usr/src/linux-headers-6.11-rc5-common/include/linux/bvec.h:10, from /usr/src/linux-headers-6.11-rc5-common/include/linux/blk_types.h:10, from /usr/src/linux-headers-6.11-rc5-common/include/linux/buffer_head.h:12, from /var/lib/dkms/linux-apfs-rw/0.3.10/build/extents.c:6: /usr/src/linux-headers-6.11-rc5-common/include/linux/minmax.h:330:9: note: this is the location of the previous definition 330 | #define MAX(a,b) __cmp(max,a,b) | ^~~ CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/symlink.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/transaction.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/unicode.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/xattr.o CC [M] /var/lib/dkms/linux-apfs-rw/0.3.10/build/xfield.o /var/lib/dkms/linux-apfs-rw/0.3.10/build/unicode.c:17:9: warning: "MIN" redefined 17 | #define MIN(X, Y) ((X) <= (Y) ? (X) : (Y)) | ^~~ In file included from /usr/src/linux-headers-6.11-rc5-common/include/linux/kernel.h:28, from /var/lib/dkms/linux-apfs-rw/0.3.10/build/unicode.c:9: /usr/src/linux-headers-6.11-rc5-common/include/linux/minmax.h:329:9: note: this is the location of the previous definition 329 | #define MIN(a,b) __cmp(min,a,b) | ^~~ /var/lib/dkms/linux-apfs-rw/0.3.10/build/transaction.c: In function 'apfs_transaction_commit_nx': /var/lib/dkms/linux-apfs-rw/0.3.10/build/transaction.c:715:17: error: implicit declaration of function 'page_mkclean'; did you mean 'pte_mkclean'? [-Wimplicit-function-declaration] 715 | page_mkclean(page); | ^~~~ | pte_mkclean make[2]: *** [/usr/src/linux-headers-6.11-rc5-common/scripts/Makefile.build:249: /var/lib/dkms/linux-apfs-rw/0.3.10/build/transaction.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:1950: /var/lib/dkms/linux-apfs-rw/0.3.10/build] Error 2 make: *** [/usr/src/linux-headers-6.11-rc5-common/Makefile:236: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-6.11-rc5-amd64' Andreas
Bug#633998: Two down, one to go
Control: tags -1 - patch Control: tags -1 moreinfo Thanks Hi, Am Fri, Jul 11, 2014 at 04:29:43PM + schrieb Jean-Michel Nirgal Vourgère: > Just a note: It looks like patches > 0002-Make-A-not-always-use-wired-MACs.patch > 0003-Don-t-leave-with-un-initialized-ret-in-an-error-case.patch > no longer are relevant for the version in testing. Macchanger came up as a candidate for the Bug of the Day[1] and so I had a look into this bug. I realised that also the first patch does not apply to the latest upstream version. I've imported it into Salsa anyway[2] to ease the work for someone who is suffering from the problem and will be able to fix *and* *test* the patch (which I can't without much effort since I do not use this package). Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/debian/macchanger/-/blob/master/debian/patches/fix-constant-mac-addresses-in-case-they-are-specifie.patch?ref_type=heads -- https://fam-tille.de
Bug#1044330: daemonlogger uploaded to DELAYED=10
Control: tags -1 pending Thanks Hi Chris, as per ITS bug the Package Salvage team has fixed the open bugs in daemonlogger. I've uploaded the package to DELAYED=10. Kind regards Andreas. -- https://fam-tille.de
Bug#1075443: rep-gtk uploaded to DELAYED=10
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#1081235: gdebi: Migrate packaging repository to git?
On Mon, 9 Sep 2024 22:00:07 +0200 Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?= wrote: > Package: gdebi > Version: 0.9.5.7+nmu10 > Severity: normal > > Dear Maintainer, > > I'm working on importing the changes of the latest uploads into a git > repository with proper author information - is this anything that would > be welcome? Then we can set the Vcs- fields to git and use git for the > packaging fully and not the (which looks like it is abandoned) bazaar > repository. > "Proof of concept" available at https://salsa.debian.org/gusnan/gdebi I haven't imported my last NMU (10), since it was uploaded with a delay and hasn't hit the archives yet, but will of course do when and if it does. /Andreas gus...@debian.org
Bug#1075393: pocl: ftbfs with GCC-14
On 9/9/24 22:23, Stuart Prescott wrote: Another month has passed - is there something that others can help with here? That was a llvm-17 regresssion that got fixed today ;-) pocl just got built successfully on arm64 ;-) Andreas
Bug#1081235: gdebi: Migrate packaging repository to git?
Package: gdebi Version: 0.9.5.7+nmu10 Severity: normal Dear Maintainer, I'm working on importing the changes of the latest uploads into a git repository with proper author information - is this anything that would be welcome? Then we can set the Vcs- fields to git and use git for the packaging fully and not the (which looks like it is abandoned) bazaar repository. I personally believe that bzr packaging is a bit of a scare for people who wants to provide patches, and the fact that the repo isn't up to date doesn't help either, so I believe that an up to date git repo would be quite helpful. I have done two uploads recently, but not pushed them to any public repo, these I will include of course, and I believe this will help potential new contributors too. Michael Vogt (in CC), would you have anything against this? Asking, since you are listed as the maintainer, but since you haven't made any uploads since 2015, and the bazaar repository is out of date, my guess is that you wouldn't mind, but still CC'ing and asking you since you are in fact still (listed as) the maintainer. And of course it would be welcome with input from all you other people who have contributed too. /Andreas Rönnquist gus...@debian.org -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 gdebi depends on: ii gdebi-core 0.9.5.7+nmu10 ii gir1.2-gtk-3.0 3.24.43-3 ii gir1.2-vte-2.91 0.77.92-1 ii pkexec 125-2 ii python3 3.12.5-1 ii python3-gi 3.48.2-1+b1 Versions of packages gdebi recommends: pn libgtk2-perl ii lintian 2.118.1 ii shared-mime-info 2.4-5 gdebi suggests no packages. -- no debconf information
Bug#1080439: transition: exiv2 0.28.x
In article (gmane.linux.debian.devel.release) you wrote: > Control: tags -1 confirmed > On 04/09/2024 07:17, Pino Toscano wrote: >> Usertags: transition [...] , >> I'd like to request a transition for the current stable version of the >> Exiv2 library, i.e. 0.28.x (currently 0.28.3). [...] Hello, I have uploaded hugin about an hour ago and was too slow with "dcut rm". I hope it does not mess up things too badly. Afaict it shouldn't, the only new thing it adds is libvigraimpex which should propagate to testing tomorrow anyway. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1078917: webfs uploaded to DELAYED=10, tag bugs pending
Control: tags -1 pending Thanks Hi, as announced in ITS the Debian Salvage team has fixed a couple of bugs in this package and moved it to salsa. The package is now uploaded to DELAYED=10 queue. Kind regards Andreas. -- https://fam-tille.de
Bug#1081188: ITS: nuttcp
Source: nuttcp Version: 6.1.2-4 Severity: normal X-Debbugs-Cc: Chris Taylor , 1068...@bugs.debian.org, 839...@bugs.debian.org, Package Salvaging Team Hi I'm interested in salvaging your package, nuttcp, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - Bugs filed against the package do not have answers from the maintainer. - Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged. - There are QA issues with the package. I've set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/nuttcp [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#480042: mppenc uploaded to DELAYED=10
Control: tags -1 pending Thanks Hi Jorge, as announced in the ITS bug I have salvaged your package and uploaded to DELAYED=10. Kind regards Andreas. -- https://fam-tille.de
Bug#1081151: ITS: nicstat
Source: nicstat
Version: 1.95-1
Severity: normal
X-Debbugs-Cc: 847...@bugs.debian.org, 900...@bugs.debian.org,
james.tr...@canonical.com, Package Salvaging Team
Hi
I’m interested in salvaging your package, nicstat, in accordance with
the Package Salvaging procedure outlined in the Developers Reference[1].
Your package meets the criteria for this process, and I would love to
assist in preserving and maintaining it. As the Salvage process
suggests, here is a list of the criteria that apply, in my opinion:
- Bugs filed against the package do not have answers from the
maintainer.
- There are QA issues with the package.
I've set up a repository within the salvage-team space[2] to assist you
with this initial setup. If you decide not to accept the ITS, this
repository can easily be moved to another location, such as debian/, or
any place of your choosing. I hope this service helps make the
transition to using a Git repository on Salsa smoother and more
convenient for you.
Your package was highlighted in the Bug of the Day[3] initiative, which
aims to introduce newcomers to manageable tasks and guide them through
the workflow to solve them. The focus of this initiative is on migrating
packages to Salsa, as it's a great way to familiarize newcomers with a
consistent Git-based workflow.
Kind regards
Andreas.
[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://salsa.debian.org/salvage-team/nicstat
[3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5,
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1080434: exim4-base: exim4 starts before home directories are mounted
On 2024-09-03 Peter Chubb via Pkg-exim4-maintainers wrote: > Package: exim4-base > Version: 4.98-1 > Severity: normal > Dear Maintainer, > After a recent apt update and reboot, exim4 started and grabbed a > reference to /home before autofs started making home directories > available. This meant it could not deliver email. > Autofs map for /home looks like: > * nfs-server:/export/home/& > exim4 needs to look for ~/.forward when delivering email; (and we often end up > delivering into ~/Mail/inbox for each user) > I think exim4's systemd unit file needs something like > After= ... remote-fs.target autofs.service > RequireMountsFor=/home/someuser > to make sure that home directories are available by the time it starts (but > systemd is a bit of a mystery to me) [...] Hello, Adding remote-fs.target (and nss-user-lookup.target) might be a good idea. Listing autofs.target does not look right to me. There are multiple automounters and autofs.target is just one of them. I could add RequiresMountsFor=/home but not RequireMountsFor=/home/someuser because we do not have someuser that is present on all Debian systems. >From my POV this looks like somthing I cannot /generically/ carter for in the exim service file but needs to be set locally by the admin. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1079513: ITS: rsstail
Hi René, Am Fri, Sep 06, 2024 at 04:17:23PM + schrieb René Mayorga: > > Thanks Andreas for your time and your help on this package, I don't have > right now the time to care for it, Salvaging and leave it for adoption > is more than welcome. Thanks for confirming agreement and uploaded. Kind regards Andreas. -- https://fam-tille.de
Bug#1081065: RM: splay -- RoQA; Not maintained upstream, no active Debian Maintainer, more modern replacement inside Debian
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: sp...@packages.debian.org, 88...@bugs.debian.org, tony mancill , John Hedges , Package Salvaging Team Control: affects -1 + src:splay User: ftp.debian@packages.debian.org Usertags: remove Hi, as discussed in one of the bugs of splay[1] the Uploader Tony Mancill wrote: "I agree with the proposal to drop splay in favor of mp3blaster. I don't see any upstream activity whatsoever." So please remove splay from Debian. Thank you for your work as ftpmaster Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=88691#22
Bug#1077034: exim4-daemon-light: reload breaking change
On 2024-07-25 Slavko wrote: > Package: exim4-daemon-light > Version: 4.98-1 > Severity: normal > After introducing the systemd service file, the reload command has different > behaviour than previously. Previously reload (re)generated new config and > then reloads daemon. Now just daemon reload happens, thus it doesn't reflects > config changes (i use split config). > I use this in override snippet in exim4.service.d/override.conf to revert > previous behaviour: > [Service] > ExecReload= > ExecReload=/usr/sbin/update-exim4.conf $UPEX4OPTS ; \ >/bin/sh -c "/usr/sbin/exim4 -bP >/dev/null" ; \ >kill -HUP $MAINPID [...] Thank you! I think the second command is superfluous since update-exim4.conf already uses "exim -bV" to check for syntax errors, I don't think -bP improves on that. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1078750: pocl: FTBFS on arm64: Clang link test FAILED.
Followup-For: Bug #1078750 still debugging ...
Bug#1079361: Sloccount uploaded to DELAYED=10
Hi Uwe, ass announced in the ITS bug I intended to salvage sloccount. I've fixed all bugs in To: and uploaded to DELAYED=10. Kind regards Andreas. -- https://fam-tille.de
Bug#508558: Add sloc2html to sloccount package
Control: tags -1 moreinfo
Thanks
Hi,
since package sloccount came up in the Bug of the Day[1] we tried to
salvage this packege[2]. I followed your hint to add sloc2html in
Git[3]. I've used 2to3 to convert the script to Python3. Unfortunately
it does not work. If you can fix the script I'd happily add it to the
package but for the moment I do not see any advantage for our users.
Kind regards
Andreas.
[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
[2] https://bugs.debian.org/1078785
[3]
https://salsa.debian.org/salvage-team/sloccount/-/tree/master/debian/sloc2html?ref_type=heads
--
https://fam-tille.de
Bug#1009908: Tags pending in Git
Control: tags -1 pending Thanks These bugs are fixed in Git but not uploaded since bug #756997 is not fixed which seems to make such an upload not sensible. Kind regards Andreas. -- https://fam-tille.de
Bug#1080471: transition: libassuan
On 2024-09-05 Emilio Pozuelo Monfort wrote: > On 04/09/2024 18:40, Andreas Metzler wrote: [...] > > libassuan had a soname bump. The new release (3.x) is API (upwards) > > compatible. There where some minor hickups causing build-errors [1] but > > afaict we have resolved them. BinNMUs of rdeps should now be sufficient. > > > > It probably makes sense to delay this until gpgme1.0 >= 1.18.0-6 has > > propagated to testing to avoid coupling this transitions with the > > python3-setuptools update (See #1079928). > gpgme1.0 will migrate in ~1h, as I have hinted it. So you can go ahead with > this already. We'll avoid NMU-ing it until it has migrated. Hello, I have uploaded libassuan and gpgme1.0 has propagated to testing. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
Control: tag -1 pending src:nvidia-graphics-drivers for bookworm-backports is in BACKPORTS-NEW. On 9/4/24 17:15, Stefano Zacchiroli wrote: On Tue, Sep 03, 2024 at 06:35:06PM +0200, fr.hame...@gmail.com wrote: To solve it have applied the patches given by nvidia the 21 of July here : https://forums.developer.nvidia.com/t/gpl-only-symbols-follow-pte-and-rcu-read-unlock-prevent-470-256-02-to-build-with-kernel-6-10/300052/4 I can confirm it worked for me too, thanks a lot for the pointer! For convenience, I'm attaching the patch I used to this message (its 2 messages down from the above, but it's not directly downloadable). It does not apply cleanly to nvidia-kernel-dkms 535.183.01-1~deb12u1 , but it's trivial to fix manually. Just curious: Why didn't you simply rebuild the package from sid for bookworm instead of digging for patches on the internet? Andreas
Bug#1080220: FTBFS: error: invalid command 'test'
Uploaded with 10 day delay, as mentioned. best /Andreas gus...@debian.org
Bug#1080385: ITS: pcal
Ahhh, I forgot to say if you also object to maintain the package on Salsa at all I can remove it from there. With QA issues I meant the things I've fixed in changelog - no other things. Kind regards Andreas. Am Thu, Sep 05, 2024 at 01:20:51PM -0400 schrieb Camm Maguire: > Greetings, and thank you so much for this report! > > I'd prefer to keep maintaining this package as is (so I 'object' to the > ITS), but do acknowledge that the existing bugs need better processing. > I will upload a new version soon that either forwards, closes, or tags > these wont-fix. As upstream is dormant for this package, I will also > consider applying submitted patches for desired missing features, > etc. I'm certainly open to any other suggestions as well, other than > group maintainership and the like. > > I'm unclear if you feel there are QA issues apart from those filed in > the BTS. If so please let me know. I've briefly checked your reference > [3] and could not quickly find any reference to pcal. > > Take care, > > Andreas Tille writes: > > > Source: pcal > > Version: 4.11.0-3 > > Severity: normal > > X-Debbugs-Cc: 900...@bugs.debian.org, Camm Maguire , > > Package Salvaging Team > > > > Hi > > > > I’m interested in salvaging your package, pcal, in accordance with the > > Package Salvaging procedure outlined in the Developers Reference[1]. > > Your package meets the criteria for this process, and I would love to > > assist in preserving and maintaining it. As the Salvage process > > suggests, here is a list of the criteria that apply, in my opinion: > > > > - Bugs filed against the package do not have answers from the > > maintainer. > > - There are QA issues with the package. > > > > I’ve set up a repository within the salvage-team space[2] to assist you > > with this initial setup. If you decide not to accept the ITS, this > > repository can easily be moved to another location, such as debian/, or > > any place of your choosing. I hope this service helps make the > > transition to using a Git repository on Salsa smoother and more > > convenient for you. > > > > Your package was highlighted in the Bug of the Day[3] initiative, which > > aims to introduce newcomers to manageable tasks and guide them through > > the workflow to solve them. The focus of this initiative is on migrating > > packages to Salsa, as it's a great way to familiarize newcomers with a > > consistent Git-based workflow. > > > > Kind regards > > Andreas. > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > [2] https://salsa.debian.org/salvage-team/pcal > > [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks > > > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), > > (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) > > Kernel taint flags: TAINT_WARN > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 > > -- > Camm Maguire c...@maguirefamily.org > == > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > -- https://fam-tille.de
Bug#1080385: ITS: pcal
Hi Camm, Am Thu, Sep 05, 2024 at 01:20:51PM -0400 schrieb Camm Maguire: > Greetings, and thank you so much for this report! You are welcome. > I'd prefer to keep maintaining this package as is (so I 'object' to the > ITS), but do acknowledge that the existing bugs need better processing. > I will upload a new version soon that either forwards, closes, or tags > these wont-fix. As upstream is dormant for this package, I will also > consider applying submitted patches for desired missing features, > etc. I'm certainly open to any other suggestions as well, other than > group maintainership and the like. OK, I've moved the package to https://salsa.debian.org/debian/pcal/ It would be great if you could maintain the package on Salsa. > I'm unclear if you feel there are QA issues apart from those filed in > the BTS. If so please let me know. I've briefly checked your reference > [3] and could not quickly find any reference to pcal. We do not track the packages we are working on there. Its just to explain what Bug of the Day means. > Take care, Thank you for maintaining pcal Andreas. > Andreas Tille writes: > > > Source: pcal > > Version: 4.11.0-3 > > Severity: normal > > X-Debbugs-Cc: 900...@bugs.debian.org, Camm Maguire , > > Package Salvaging Team > > > > Hi > > > > I’m interested in salvaging your package, pcal, in accordance with the > > Package Salvaging procedure outlined in the Developers Reference[1]. > > Your package meets the criteria for this process, and I would love to > > assist in preserving and maintaining it. As the Salvage process > > suggests, here is a list of the criteria that apply, in my opinion: > > > > - Bugs filed against the package do not have answers from the > > maintainer. > > - There are QA issues with the package. > > > > I’ve set up a repository within the salvage-team space[2] to assist you > > with this initial setup. If you decide not to accept the ITS, this > > repository can easily be moved to another location, such as debian/, or > > any place of your choosing. I hope this service helps make the > > transition to using a Git repository on Salsa smoother and more > > convenient for you. > > > > Your package was highlighted in the Bug of the Day[3] initiative, which > > aims to introduce newcomers to manageable tasks and guide them through > > the workflow to solve them. The focus of this initiative is on migrating > > packages to Salsa, as it's a great way to familiarize newcomers with a > > consistent Git-based workflow. > > > > Kind regards > > Andreas. > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > [2] https://salsa.debian.org/salvage-team/pcal > > [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks > > > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), > > (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) > > Kernel taint flags: TAINT_WARN > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 > > -- > Camm Maguire c...@maguirefamily.org > == > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > -- https://fam-tille.de
Bug#1080220: FTBFS: error: invalid command 'test'
On Sat, 31 Aug 2024 21:17:05 +0200 Stefano Rivera wrote:
> Source: gdebi
> Version: 0.9.5.7+nmu9
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> User: debian-pyt...@lists.debian.org
> Usertags: setup.py-test
>
> Dear maintainer,
>
> During a test rebuild for packages affected by setuptools 72, gdebi
> failed to rebuild.
>
> FWIW: I think these bugs were all caused by setuptools v72 dropping
> support for the "test" command, so dh-python has fallen back to
> distutils / other test plugins.
>
> If you're trying to figure out how to fix the bug, look at the
> implementation of test_suite in setup.py to see what magic it does for
> test setup.
>
> ---
> [...]
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> xvfb-run -a python3.12 setup.py test
> /<>/setup.py:15: SyntaxWarning: invalid escape sequence '\('
> match = compile('.*\((.*)\).*').match(head)
> /usr/lib/python3/dist-packages/setuptools/_distutils/dist.py:268:
> UserWarning: Unknown distribution option: 'test_suite'
> warnings.warn(msg)
> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>or: setup.py --help [cmd1 cmd2 ...]
>or: setup.py --help-commands
>or: setup.py cmd --help
>
> error: invalid command 'test'
> make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:7: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
>
> Build finished at 2024-08-28T00:36:39Z
>
> ---
>
I intend to NMU this shortly (with a 10 day delay), changing it to using
autopkgtest-pkg-pybuild for testing, see the attached debdiff. The
patch also removes naming Exceptions as e, and then not using the e
variable anywhere, which is needed to actually make the test pass.
Just let me know if you have any objections.
best
/Andreas
gus...@debian.org
mailingli...@gusnan.se
gdebi_nmu10.debdiff
Description: Binary data
Bug#1080358: RFS: audacious/4.4-1 -- small and fast audio player which supports lots of formats
On Mon, 2 Sep 2024 21:33:32 +0200, Mateusz Łukasik wrote: >Package: sponsorship-requests >Severity: normal > >Dear mentors, > >I am looking for a sponsor for my package "audacious": > > * Package name : audacious >Version : 4.4-1 >Alternatively, you can download the package with 'dget' using this command: > > dget > -xhttps://mentors.debian.net/debian/pool/main/a/audacious/audacious_4.4-1.dsc > >Changes since the last upload: > > audacious (4.4-1) unstable; urgency=medium > . >* New upstream release. >* Add qt6-svg-dev to B-D. (Closes: #1060436) >* Bump libraries sonames. >* Update d/copyright. >* Remove COPYING file from install. >* Bump Standards-Version to 4.7.0. >* Add Bug-Database to debian/upstream/metadata. >* Update symbols files. >* Refresh debian/source/lintian-overrides. >* Add Forwarded: not-needed to Debian patches. > >Regards, Building and installing this and the plugins package, it runs just fine, but going to the about dialog it shows nothing in the license tab, and gives >ERROR ../src/libaudcore/vfs_local.cc:120 [fopen]: >/usr/share/audacious/COPYING: No such file or directory ERROR >../src/libaudcore/vfs.cc:406 [read_file]: Cannot open >/usr/share/audacious/COPYING for reading: No such file or directory in the terminal, which might be due to >* Remove COPYING file from install. Please check it out. Maybe you did intend to reference a system version of that file there? -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org
Bug#1080472: Fix dbmnz crash in exim stable update
Package: exim4-daemon-heavy
Version: 4.96-15
Severity: important
Tags: patch
Hello Sebastian,
thank for taking the time to debug and verify the patch. Lets open a
bug report to track this.
cu Andreas
--- Begin Message ---
Hello!
The email list system for our organization does lookups in Berkeley DB
databases to determine where to send emails. There is however a bug,
introduced with bookworm, that makes exim crash when looking up keys
with no content. In our case, this means that we are unable to deliver
email through the email list system if there exists emtpy email lists. A
description of this bug can be seen in the bug tracker of exim:
https://bugs.exim.org/show_bug.cgi?id=3079
The bug has been patched in upstream
(a7e6ad0ba38cf088e841c321042f81966d846b4b), but it is not included in
the stable release. Would it be possible to include this fix in the
package in debian stable? I've included a patch below my singature. The
patch is an alteration of the commit that fixed the issue. I've replaced
src/src with src, removed the test case (since quilt did not support
binary diffs), and removed the changelog (since it is not included in
the debian source). I've have tested the patch, and it seemed to resolve
our issue!
--
Sebastian Bugge
Billig-uansvarlig
ITK, Samfundet
--
>From a7e6ad0ba38cf088e841c321042f81966d846b4b Mon Sep 17 00:00:00 2001
From: Jeremy Harris
Date: Sat, 16 Mar 2024 13:50:45 +
Subject: [PATCH] Lookups: fix dbmnz crash on zero-length datum. Bug 3079
Broken-by: 6d2c02560e5c
---
src/dbfn.c | 12 +++-
src/exim_dbutil.c| 12 +++-
src/lookups/dbmdb.c | 5 -
3 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/src/dbfn.c b/src/dbfn.c
index 3c51162a4..460fd8bb7 100644
--- a/src/dbfn.c
+++ b/src/dbfn.c
@@ -239,12 +239,13 @@ Returns: a pointer to the retrieved record, or
*/
void *
-dbfn_read_with_length(open_db *dbblock, const uschar *key, int *length)
+dbfn_read_with_length(open_db * dbblock, const uschar * key, int * length)
{
-void *yield;
+void * yield;
EXIM_DATUM key_datum, result_datum;
int klen = Ustrlen(key) + 1;
uschar * key_copy = store_get(klen, key);
+unsigned dlen;
memcpy(key_copy, key, klen);
@@ -260,9 +261,10 @@ if (!exim_dbget(dbblock->dbptr, &key_datum,
&result_datum)) return NULL;
/* Assume the data store could have been tainted. Properly, we should
store the taint status with the data. */
-yield = store_get(exim_datum_size_get(&result_datum), GET_TAINTED);
-memcpy(yield, exim_datum_data_get(&result_datum),
exim_datum_size_get(&result_datum));
-if (length) *length = exim_datum_size_get(&result_datum);
+dlen = exim_datum_size_get(&result_datum);
+yield = store_get(dlen, GET_TAINTED);
+memcpy(yield, exim_datum_data_get(&result_datum), dlen);
+if (length) *length = dlen;
exim_datum_free(&result_datum);/* Some DBM libs require freeing */
return yield;
diff --git a/src/exim_dbutil.c b/src/exim_dbutil.c
index 3f70c2fd5..4d213773b 100644
--- a/src/exim_dbutil.c
+++ b/src/exim_dbutil.c
@@ -407,12 +407,13 @@ Returns: a pointer to the retrieved record, or
*/
void *
-dbfn_read_with_length(open_db *dbblock, const uschar *key, int *length)
+dbfn_read_with_length(open_db * dbblock, const uschar * key, int * length)
{
-void *yield;
+void * yield;
EXIM_DATUM key_datum, result_datum;
int klen = Ustrlen(key) + 1;
uschar * key_copy = store_get(klen, key);
+unsigned dlen;
memcpy(key_copy, key, klen);
@@ -426,9 +427,10 @@ if (!exim_dbget(dbblock->dbptr, &key_datum,
&result_datum)) return NULL;
/* Assume for now that anything stored could have been tainted. Properly
we should store the taint status along with the data. */
-yield = store_get(exim_datum_size_get(&result_datum), GET_TAINTED);
-memcpy(yield, exim_datum_data_get(&result_datum),
exim_datum_size_get(&result_datum));
-if (length) *length = exim_datum_size_get(&result_datum);
+dlen = exim_datum_size_get(&result_datum);
+yield = store_get(dlen, GET_TAINTED);
+memcpy(yield, exim_datum_data_get(&result_datum), dlen);
+if (length) *length = dlen;
exim_datum_free(&result_datum);/* Some DBM libs require freeing */
return yield;
diff --git a/src/lookups/dbmdb.c b/src/lookups/dbmdb.c
index aa930e654..96665b6e4 100644
--- a/src/lookups/dbmdb.c
+++ b/src/lookups/dbmdb.c
@@ -102,7 +102,8 @@ exim_datum_size_set(&key, length);
if (exim_dbget(d, &key, &data))
{
- *result = string_copyn(exim_datum_data_get(&data),
exim_datum_size_get(&data));
+ unsigned len = exim_datum_size_get(&data);
+ *result = len > 0 ? string_copyn(exim_datum_data_get(&data), len) : US"";
exim_datum_free(&data);/* Some DBM libraries need a free() call
*/
return OK;
}
@@ -283,3 +284,5 @@ static lookup_info *_lookup_list[] = { &dbm_lookup_info,
&dbmz_lookup
Bug#1080471: transition: libassuan
Package: release.debian.org Severity: normal Control: affects -1 + src:libassuan User: release.debian@packages.debian.org Usertags: transition libassuan had a soname bump. The new release (3.x) is API (upwards) compatible. There where some minor hickups causing build-errors [1] but afaict we have resolved them. BinNMUs of rdeps should now be sufficient. It probably makes sense to delay this until gpgme1.0 >= 1.18.0-6 has propagated to testing to avoid coupling this transitions with the python3-setuptools update (See #1079928). Ben file: title = "libassuan"; is_affected = .depends ~ "libassuan0" | .depends ~ "libassuan9"; is_good = .depends ~ "libassuan9"; is_bad = .depends ~ "libassuan0"; cu Andreas [1] * The new release drops /usr/bin/libassuan-config. * The api_version= field in pkg-config data was also bumped from 2 to 3. Both required changes to autoconf scripts and similar stuff in rdeps. -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' signature.asc Description: PGP signature
Bug#88691: Maintaining splay in Debian Multimedia team?
Hi John and Tony, the package splay showed up as candidate for the Bug of the Day[3]. Since I know Tony as an active maintainer and sponsor of packages I do not file our "Intend to Salvage" template uncommented via BTS. Moreover I've read in bug #88691 that mp3blaster is a "heavily modified version of splay" and some patch for this bug was suggested. While mp3blaster is maintained by "Debian QA group" it has a higher popcon than splay. So I would like to discuss with you whether it makes sense to drop splay in favour of mp3blaster, we move the latter to Debian Multimedia team and you might serve as Uploader there. All four open bugs of mp3blaster are tagged patch and I would volunteer to migrate this package to the Salsa team space and do some team upload. Just let me know whether according to your better insight into splay it makes sense to keep it in Debian and to move it to the team repository. I would also like to know how you would have an ITS bug with the text below would have perceived. This initiative is relatively new and we experienced that some maintainer felt offended which we would really like to avoid. Kind regards Andreas ... and now there is the ITS template. Hi I’m interested in salvaging your package splay, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - Bugs filed against the package do not have answers from the maintainer. a bug entry asking for it, it has not been packaged. - There are QA issues with the package. I believe your package would be a great addition to the Debian Multimedia team, and created the Salsa repository here[2]. If you choose not to accept the ITS, I’d be more than happy to help you move it to another location, such as debian/, or wherever you prefer. My goal is to make it as easy as possible for you to join the team. I’d also be delighted to assist in adding you as a team member if you could share your Salsa login. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/multimedia-team/splay [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- https://fam-tille.de
Bug#1080299: RFS: dia/0.98+git20240814-1 -- Diagram editor
On Tue, 3 Sep 2024 22:57:32 +0200, Philippe SWARTVAGHER wrote: >Hello, > >Le 03/09/2024 à 08:28, Phil Wyett a écrit : >>> Hey - I'll sponsor this, but i would like to see something more >>> descriptive for the closing of the bug in the changelog: >>> >>>> Changes since the last upload: >>>> >>>> dia (0.98+git20240814-1) unstable; urgency=medium >>>> . >>>> * New upstream snapshot >>>> - Closes: #1078335 >>>> * Remove patches applied upstream >>>> * Build-depend on libemf-dev only on available architectures >>>> >>> perhaps something like >>> >>>> * New upstream snapshot >>>> - Fix adding images to diagrams - Closes: #1078335 >>>> * Remove patches applied upstream >>>> * Build-depend on libemf-dev only on available architectures > >Done. > > > >> Could the below files be appropriately handled in 'debian/copyright' >> >> philwyett@ks-tarkin:~/Development/builder/debian/mentoring/dia- >> 0.98+git20240814$ lrc >> : Versions: recon 1.16 check 3.3.9-1 >> >> Parsing Source Tree >> Reading copyright >> Running licensecheck >> >> d/copyright | licensecheck >> >> GPL-2 | public-domainplug-ins/layout/ogdf-simple.cpp >> GPL-2 | public-domainplug-ins/layout/ogdf-simple.h > >Done. > >> GPL-2 | MIT~Xfig plug-ins/xfig/fig-format-3.2 > >This one seems like a false-positive: the copyright of this file is not >clear, but I cannot find any mention about "MIT-Xfig" in this file or >even in the whole project. > >I uploaded to mentors the updated package: >https://mentors.debian.net/package/dia/. > >Thanks for your reviews, > Thank you! I'll get it uploaded tonight (shortly). best -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org
Bug#1080385: ITS: pcal
Source: pcal Version: 4.11.0-3 Severity: normal X-Debbugs-Cc: 900...@bugs.debian.org, Camm Maguire , Package Salvaging Team Hi I’m interested in salvaging your package, pcal, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I’ve set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/pcal [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1079816: ROM: artennavis (Was: Bug#1079816: ITS: antennavis)
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: antennavis -- RoQA; dead upstream, replaced by more modern tools Thanks Hi, just following Christoph's advise and asking for removal of this package. Kind regards Andreas. Am Mon, Sep 02, 2024 at 06:01:05PM +0200 schrieb Christoph Berg: > Re: Andreas Tille > > I would like to salvage your package antennavis by following the Package > > Salvaging procedur which is described in Developers Reference[1]. > > Fwiw, I believe this package is a candidate for removal. > > The last upstream version is from 2010. I cannot believe it is still > useful, even when replacing the obsolete "nec" dependency by "nec2c". > The xnec2c package provides visualization of the simulation results > and should be a replacement for antennavis. > > http://www.include.gr/antennavis.html > > Christoph > -- https://fam-tille.de
Bug#1080299: RFS: dia/0.98+git20240814-1 -- Diagram editor
Control: owner -1 gus...@debian.org On Sun, 1 Sep 2024 18:29:35 +0200, Philippe SWARTVAGHER wrote: >Dear mentors, > >I am looking for a sponsor for my package "dia": > Hey - I'll sponsor this, but i would like to see something more descriptive for the closing of the bug in the changelog: >Changes since the last upload: > > dia (0.98+git20240814-1) unstable; urgency=medium > . >* New upstream snapshot > - Closes: #1078335 >* Remove patches applied upstream >* Build-depend on libemf-dev only on available architectures > perhaps something like >* New upstream snapshot > - Fix adding images to diagrams - Closes: #1078335 >* Remove patches applied upstream >* Build-depend on libemf-dev only on available architectures best -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org
Bug#1080143: urfkill: FTBFS: checking Session tracking support... ./configure: line 15715: syntax error near unexpected token `;;'
Control: tags -1 patch On 2024-08-30 Santiago Vila wrote: > Package: src:urfkill > Version: 0.5.0-7.2 > Severity: serious > Tags: ftbfs > Dear maintainer: > During a rebuild of all packages in unstable, your package failed to build: > > [...] This is caused by AC_MSG_ERROR([--with-session-tracking must be systemd/consolekit/no, not $with_session_tracking])) New autoconf seems to split on the comma, producing invalid code. Double-quoting with [[ ]] works for me. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' Description: Double quote AC_MSG_ERROR arg to avoid split on comma. Author: Andreas Metzler Bug-Debian: https://bugs.debian.org/1080143 Origin: vendor Last-Update: 2024-08-31 --- urfkill-0.5.0.orig/configure.ac +++ urfkill-0.5.0/configure.ac @@ -184,7 +184,7 @@ AS_IF([test "$with_session_tracking" = " AS_IF([test "$with_session_tracking" = "none"], with_session_tracking=no) # check value AS_IF([! (echo "$with_session_tracking" | grep -q -E "^(systemd|consolekit|no)$")], -AC_MSG_ERROR([--with-session-tracking must be systemd/consolekit/no, not $with_session_tracking])) +AC_MSG_ERROR([[--with-session-tracking must be systemd/consolekit/no, not $with_session_tracking]])) # add conditionals and subtitution AM_CONDITIONAL(SESSION_TRACKING_CK, test "$with_session_tracking" = "consolekit") AM_CONDITIONAL(SESSION_TRACKING_SYSTEMD, test "$with_session_tracking" = "systemd")
Bug#1080103: e17: FTBFS: Dependency lookup for ecore-input-evas with method 'cmake' failed: CMake binary for machine host machine not found. Giving up.
Control: reassign -1 efl-all-dev 1.27.0-3 Control: reassign 1080105 efl-all-dev 1.27.0-3 Control: reassign 1080141 efl-all-dev 1.27.0-3 Control: forcemerge 1080103 1080105 1080103 On 2024-08-30 Santiago Vila wrote: > Package: src:e17 > Version: 0.26.0-4 [...] > Called: `/usr/bin/pkg-config --modversion ecore-input-evas` -> 0 > stdout: > 1.27.0 > --- > env[PKG_CONFIG_PATH]: > env[PKG_CONFIG]: /usr/bin/pkg-config > --- > Called: `/usr/bin/pkg-config --cflags ecore-input-evas` -> 1 > stderr: > Package libunibreak was not found in the pkg-config search path. > Perhaps you should add the directory containing `libunibreak.pc' > to the PKG_CONFIG_PATH environment variable > Package 'libunibreak', required by 'evas', not found [...] Hello Santiago, all three of these bugs are caused by ... (sid)ametzler@argenau:/tmp/E17/e17$ grep Req /usr/lib/x86_64-linux-gnu/pkgconfig /evas.pc Requires: eina, ecore, ector, emile, efl, eo Requires.private: eet, lua51 < 5.2.0, lua51 >= 5.1.0, libunibreak >= 4.2, freetype2, fontconfig, fribidi, harfbuzz, wayland-client, libjpeg, libpng ... without libefl-all-dev depending (even indirectly) on libunibreak-dev. I suspect one of libefl-all-dev's dependencies used to depend on it and stopped doing so. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1080175: ITS: funnelweb
Source: funnelweb Version: 3.2-5 Severity: normal X-Debbugs-Cc: Yann Dirson , 929...@bugs.debian.org, Package Salvaging Team Hi I’m interested in salvaging your package, funnelweb, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. Your package meets the criteria for this process, and I would love to assist in preserving and maintaining it. As the Salvage process suggests, here is a list of the criteria that apply, in my opinion: - NMUs, especially if there has been more than one NMU in a row. - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I’ve set up a repository within the salvage-team space[2] to assist you with this initial setup. If you decide not to accept the ITS, this repository can easily be moved to another location, such as debian/, or any place of your choosing. I hope this service helps make the transition to using a Git repository on Salsa smoother and more convenient for you. Your package was highlighted in the Bug of the Day[3] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/funnelweb [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1079958: Should epigrass be removed from unstable?
Hi, probably we should remove epigrass. It seems way harder to get dash and panel trough NEW than getting epigrass accepted again once these might be in Debian. Sad to see it go since it could help in the next pandemic but if its not working there is no point to leave it. CCing Debian Med list to find motivated persons for dash ... which might be great for lots of scientific tools. Kind regards Andreas. -- https://fam-tille.de
Bug#1079858: ITS: textdraw
Dear Rene, I’m truly sorry for having disappointed you. My mistake stemmed from a misjudgment on my part, as I mistakenly assumed that you might have shifted focus away from this smaller package due to your extensive work on larger projects like LibreOffice and its infrastructure. I greatly appreciate all your efforts on these major packages and simply wanted to offer a helping hand with a more straightforward task. Unfortunately, this led to another incorrect assumption—that it might be acceptable to apply the same formalism that worked in other, admittedly more critical, cases. To soften this approach, I added a personal remark, hoping to ensure the process wouldn’t be misunderstood. Regrettably, that attempt didn’t succeed, and I realize now that I shouldn’t have relied on our previous in-person interactions and your awareness of the deep respect I have for your work. If it would help, I owe you a $DRINK the next time we meet. Am Wed, Aug 28, 2024 at 07:48:28PM +0200 schrieb Rene Engelhard: > Am 28.08.24 um 19:36 schrieb Andreas Tille: > > Could you please give some example for what you conaiser "quite nicely"? > > Not filing a RFS in the first place (with even already importing the stuff > into a salvage team space, referring reasons OK, I tried to learn from my mistake by 1. Fixing the template to maintain a friendly tone in the ITS template while being more informative that the intention is to help. [A1] 2. Moved the repository I've created to debian/ [A2] for your kind inspection, fixing both open bugs and an outdated Build-Depends that was claimed by lintian. Moreover I turned the watch file into something which will not create any noise on your Maintainer dashboard (that's a minor thing but helps parsing a lot of packages to keep out noise like this[A3] as well as tracker hinting about "uscan had problems while searching for a new upstream version") > fr salvaging which *all* do not apply in this package[1]) and no open bugs > which warrant any "salvaging". I acknowledge that "salvaging" might seem like a strong word in this context, but I respectfully disagree in principle regarding the FTBCFS bug[A4]. When a fellow DD took the time to create a non-trivial patch aimed at improving Debian’s adaptability to new architectures, I believe this provided a strong justification for a timely upload. In light of the thread "Removing more packages from unstable"[A5] (and although I acknowledge that textdraw is not affected since the bug is not RC), I believe it can be discouraging for active contributors to see the time and effort they’ve invested not yielding results over an extended period. > But asking per mail whether it could be moved to "Debian". I can’t change what has already happened, but I hope that my clarification, the move to debian/, and my commitment to improving the template’s wording will help you accept my apology. Kind regards and hopefully see you at next DebConf for sharing some $DRINK Andreas. > [1] I don't reply to obvious stuff wher ethere's no more info needed like the > typo fix or the FTBCFS one (however uneeded that one is inself, maybe I > should have done) [A1] https://salsa.debian.org/tille/tiny_qa_tools/-/commit/b0fad5a2c18b5f692fe4e78d56ecfaa85f75a11f [A2] https://salsa.debian.org/debian/textdraw [A3] https://udd.debian.org/dmd/?email1=&email2=&email3=&packages=textdraw&ignpackages=&format=html#todo [A4] https://bugs.debian.org/1024931 [A5] https://lists.debian.org/debian-devel/2024/08/msg00298.html -- https://fam-tille.de
Bug#926660: Patch to make webfs stoppable again
Hi Sebastien, Am Wed, May 15, 2024 at 02:19:01PM +0200 schrieb Sebastien KOECHLIN: > The /etc/logrotate.d/webfs file should probably be patched the same way: > > May 15 00:00:00 X systemd[1]: Starting Rotate log files... > May 15 00:00:00 X logrotate[34644]: start-stop-daemon: matching only on > non-root pidfile /var/run/webfs/webfsd.pid is insecure > May 15 00:00:00 X logrotate[34637]: error: error running non-shared > postrotate script for /var/log/webfs/webfs.log of '/var/log/webfs/webfs.log ' > May 15 00:00:00 X systemd[1]: logrotate.service: Main process exited, > code=exited, status=1/FAILURE > May 15 00:00:00 X systemd[1]: logrotate.service: Failed with result > 'exit-code'. > May 15 00:00:00 X systemd[1]: Failed to start Rotate log files. Since webfs came up in the Bug of the Day[1] on 2024-08-17 I've filed an ITS bug. Once the waiting period is over I will probably upload. You can support this by providing a full patch which you might possibly have tested at your site. Thank you Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- https://fam-tille.de
Bug#1079858: ITS: textdraw
Hi Rene, Am Wed, Aug 28, 2024 at 04:07:27PM +0200 schrieb Rene Engelhard: > [ greeting intentionally left out ] greeting intentionally added. > A personal note: If you did ask quite nicely I 'd have agreed. It might have > make sense. Could you please give some example for what you conaiser "quite nicely"? I've added a personal note just for this purpose but obviously failed. I'd love to do better next time and I would love to explain the reason why I filed this bug ... but not in this temper, sorry. Kind regards Andreas. -- https://fam-tille.de
Bug#1079928: gpgme1.0: FTFBFS with python3-setuptools 73.0.1-1
Source: gpgme1.0
Version: 1.18.0-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: python3-setupto...@packages.debian.org, ametz...@debian.org
Hello,
gpgme1.0 has recently started to FTBFS on current sid while it build
successfully on trixie:
--
make[6]: Leaving directory
'/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/tests'
for PYTHON in /usr/bin/python3.12 ; do \
GNUPGHOME=/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/tests LC_ALL=C
GPG_AGENT_INFO= top_srcdir=../../../.. srcdir=../../../../lang/python/tests
LD_LIBRARY_PATH="../../../src/.libs:" $PYTHON
../../../../lang/python/tests/run-tests.py \
--interpreters="/usr/bin/python3.12 " --srcdir=../../../../lang/python/tests
\
initial.py t-wrapper.py t-callbacks.py t-data.py t-encrypt.py
t-encrypt-sym.py t-encrypt-sign.py t-sign.py t-signers.py t-decrypt.py
t-verify.py t-decrypt-verify.py t-sig-notation.py t-export.py t-import.py
t-edit.py t-keylist.py t-keylist-from-data.py t-wait.py t-encrypt-large.py
t-file-name.py t-idiomatic.py t-protocol-assuan.py t-quick-key-creation.py
t-quick-subkey-creation.py t-quick-key-manipulation.py t-quick-key-signing.py
final.py ; \
done
Traceback (most recent call last):
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/tests/../../../../lang/python/tests/initial.py",
line 24, in
import gpg
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/__init__.py",
line 123, in
from . import core
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/core.py",
line 10, in
from . import gpgme
ImportError: cannot import name 'gpgme' from partially initialized module 'gpg'
(most likely due to a circular import)
(/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/__init__.py)
Traceback (most recent call last):
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/tests/../../../../lang/python/tests/t-wrapper.py",
line 20, in
import gpg
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/__init__.py",
line 123, in
from . import core
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/core.py",
line 10, in
from . import gpgme
ImportError: cannot import name 'gpgme' from partially initialized module 'gpg'
(most likely due to a circular import)
(/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/__init__.py)
Traceback (most recent call last):
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/tests/../../../../lang/python/tests/t-callbacks.py",
line 24, in
import gpg
File
"/home/ametzler/X/gpgme1.0-1.18.0/build/lang/python/python3.12-gpg/lib.linux-armhf-cpython-312/gpg/__init__.py",
line 123, in
from . import core
[...]
--
I have debugged this insofar that downgrading
python3-pkg-resources/python3-setuptools to the trixie version
(70.3.0-2) and additionally removing python packages not present in the
trixie package list (python3-zipp python3-inflect
python3-jaraco.functools python3-more-itertools python3-typeguard
python3-typing-extensions) lets the build succeed.
Only downgrading python3-pkg-resources/python3-setuptools withou
removing the other packages seems to result in further breakage:
===
set -e ; for PYTHON in /usr/bin/python3.12 ; do \
CPP="gcc -E" \
CFLAGS="-g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/tmp/GPGME/gpgme=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall
-Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k
-Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length
-Wno-format-truncation -Wno-sizeof-pointer-div" \
srcdir="../../../lang/python" \
top_builddir="../.." \
$PYTHON setup.py build --verbose --build-base="$(basename "${PYTHON}")-gpg"
; \
done
Traceback (most recent call last):
File "/tmp/GPGME/gpgme/build/lang/python/setup.py", line 21, in
from distutils.core import setup, Extension
ModuleNotFoundError: No module named 'distutils'
make[4]: *** [Makefile:760: all-local] Error 1
===
cu Andreas
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.10.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#1079927: gnupg-pkcs11-scd: FTBFS against assuan 3
Package: gnupg-pkcs11-scd
Version: 0.10.0-4
Severity: important
Tags: patch
Hello,
gnupg-pkcs11-scd FTBFS against libassuan 3 (available in experimental)
| checking for libassuan... configure: error: Need assuan-2
libassuan version 3.x is upwards compatible with 2.x.
Patching configure.ac lets the build succeed.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Description: also accept libassuan version 3.x
Author: Andreas Metzler
Origin: vendor
Bug: https://github.com/alonbl/gnupg-pkcs11-scd/issues/62
Last-Update: 2024-08-28
--- gnupg-pkcs11-scd-0.10.0.orig/configure.ac
+++ gnupg-pkcs11-scd-0.10.0/configure.ac
@@ -232,7 +232,7 @@ AC_ARG_VAR([LIBASSUAN_LIBS], [linker fla
if test -z "${LIBASSUAN_LIBS}"; then
AC_MSG_CHECKING([for libassuan])
test -x "/usr/bin/pkg-config" || AC_MSG_ERROR([Cannot locate libassuan])
- /usr/bin/pkg-config --modversion libassuan | grep "^2\." > /dev/null || AC_MSG_ERROR([Need assuan-2])
+ /usr/bin/pkg-config --modversion libassuan | grep -E "^2\.|^3\." > /dev/null || AC_MSG_ERROR([Need assuan-2 or assuan-3])
AC_MSG_RESULT([found])
Bug#1079861: wmctrl: ITS wmctrl
Source: wmctrl Version: 1.07-7 Severity: normal X-Debbugs-Cc: Jeroen Schot , 846...@bugs.debian.org, 1011...@bugs.debian.org, 683...@bugs.debian.org, 683...@bugs.debian.org, 516...@bugs.debian.org, Package Salvaging Team Hi I would like to salvage your package wmctrl by following the Package Salvaging procedur which is described in Developers Reference[1]. Your package is fulfilling the following criteria for the salvage process: - NMUs, especially if there has been more than one NMU in a row. - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I have created a repository inside the salvage-team space[2] which is just fixing a few of the bugs. Your package showed up in the Bug of the Day[3] initiative. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/wmctrl [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1079858: ITS: textdraw
Source: textdraw Version: 0.2+ds-0+nmu1 Severity: normal X-Debbugs-Cc: Rene Engelhard , 924...@bugs.debian.org, 1024...@bugs.debian.org, Package Salvaging Team Hi Rene I would like to salvage your package textdraw by following the Package Salvaging procedur which is described in Developers Reference[1]. Your package is fulfilling the following criteria for the salvage process: - NMUs, especially if there has been more than one NMU in a row. - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I have created a repository inside the salvage-team space[2]. Your package showed up in the Bug of the Day[3] initiative. Rene, as a personal note since we know for a long time: I know you are doing great work on a lot of way more important packages. I simply would love to see also those tiny, low maintenance packages available on Salsa. Its a really great example for the newcomers that should be attracted by the Bug of the Day initiative. Thanks a lot for all your other work. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/textdraw [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1079816: ITS: antennavis
Source: antennavis Version: 0.3.1-4 Severity: normal X-Debbugs-Cc: Package Salvaging Team , Chrysostomos Nanakos , 1074...@bugs.debian.org, 923...@bugs.debian.org Hi I would like to salvage your package antennavis by following the Package Salvaging procedur which is described in Developers Reference[1]. Your package is fulfilling the following criteria for the salvage process: - Bugs filed against the package do not have answers from the maintainer. - There are QA issues with the package. I think your package is a good fit for the Debian Hamradio Maintainers and thus I will create the Salsa repository here[2]. Your package showed up in the Bug of the Day[3] initiative. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/debian-hamradio-team/antennavis [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#742510: Issue moved upstream
Control: tags -1 - fixed-upstream Forwarded: https://gitlab.freedesktop.org/xorg/driver/xf86-video-cirrus/-/issues/4 Thanks The issue was moved by upstream and thus erroneously tagged fixed-upstream. -- https://fam-tille.de
Bug#1079730: devscripts: bts does not work with mail-submit.debian.org:587 in bookworm
Package: devscripts Version: 2.23.4+deb12u1 Severity: serious Control: fixed -1 2.23.6 Control: found -1 2.23.4 bts in bookworm does not work with mail-submit.debian.org:587 This is a regression over 2.22.2~bpo11+1 which I used in bullseye It is fixed in sid. (Commit dd2ac025db69bc78ca62391153ce4e74215e4903) Andreas -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- BTS_DEFAULT_CC=a...@debian.org BTS_SMTP_HOST=mail-submit.debian.org:587 BTS_SMTP_AUTH_USERNAME= BTS_SMTP_AUTH_PASSWORD= -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (845, 'stable-updates'), (845, 'stable-security'), (845, 'stable-debug'), (845, 'stable'), (844, 'proposed-updates-debug'), (844, 'proposed-updates'), (700, 'testing-debug'), (700, 'testing'), (600, 'unstable-debug'), (600, 'unstable'), (130, 'experimental-debug'), (130, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.7+bpo-amd64 (SMP w/14 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1079707: firmware-sof: please provide an updated version in bookworm-backports
Source: firmware-sof Version: 2.2.4-1 Severity: wishlist bookworm-backports has a recent enough kernel to support my new T16, but audio only started to work after I installed firmware-sof-signed from sid. Could you provide a newer version of the firmware in bookworm-backports? Thanks Andreas
Bug#1063660: firmware-nonfree: Please backport newer firmware to Bookworm
On Mon, 29 Jul 2024 14:47:57 +0200 =?UTF-8?Q?Dylan_A=C3=AFssi?= wrote: As we now have a new version of firmware-nonfree in deb/testing, is there a backport planned? I'm willing to prepare the package if no one is against it. I'm supporting this request. My new notebook needs an updated firmware-iwlwifi and linux-image-amd64 from bookworm-backports for working wireless on an otherwise bookworm system. Andreas
Bug#1077971: Uploaded to DELAYED=10, tags pending
Control: tags -1 pending Thanks Hi, I've moved the package to Debian Multimedia Team[1] and uploaded to DELAYED=10 since the waiting period for the ITS bug is over. All bugs in To: are fixed by the pending upload. Kind regards Andreas. [1] https://salsa.debian.org/multimedia-team/alsaplayer -- https://fam-tille.de
Bug#967251: Forwarded upstream
Control: tags -1 upstream Control: forwarded -1 https://github.com/alsaplayer/alsaplayer/issues/32 Thanks Hi, alsaplayer showed up in the Bug of the Day[1] some time ago and thus I filed an ITS bug[2]. The waiting period of 21 days is over and I've moved the package to the Debian Multimedia Team[3]. I do not (yet) intend to fix this bug by following the suggestion to drop the binary package alsaplayer-gtk. For the moment I've filed an issue upstream to either upgrade to some more recent GTK version or at least provide some command line option to drop the GTK support which will probably simplify removing the package by not creating the need to patch the build system. For sure patches are welcome to forward these upstream. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://bugs.debian.org/1077971 [3] https://salsa.debian.org/multimedia-team/alsaplayer -- https://fam-tille.de
Bug#1014336: libapache2-mod-xsendfile uploaded to delayed=10
Control: tags -1 pending
Thanks
Hi Marco,
your package libapache2-mod-xsendfile, showed up as candidate of the Bug
of the Day[1]. Since I've found the Git repository in the debian/ team
(thanks to Jelmer who salvaged the repository from Alioth collab-maint)
I took the freedom to fix the three bugs in CC, modernized the packaging
to latest standards and also fetched latest Upstream commit as suggested
in one of the bug reports.
You can find the packaging I've uploaded to DELAYED=10 on Salsa[2].
Kind regards
Andreas.
[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
[2] https://salsa.debian.org/debian/libapache2-mod-xsendfile
--
https://fam-tille.de
Bug#1079565: bookworm-pu: package glogic/2.6-6+deb12u1 (pre-approval)
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: glo...@packages.debian.org
Control: affects -1 + src:glogic
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
glogic crashes on startup in stable:
>/usr/lib/python3/dist-packages/glogic/MainFrame.py:4: PyGIWarning: Gtk
>was imported without specifying a version first. Use
>gi.require_version('Gtk', '4.0') before import to ensure that the
>right version gets loaded.
> from gi.repository import Gtk, Gdk, GdkPixbuf
>Traceback (most recent call last):
> File "/usr/bin/glogic", line 20, in
>from glogic.MainFrame import MainFrame
> File "/usr/lib/python3/dist-packages/glogic/MainFrame.py", line 18,
> in themed_icons = Gtk.IconTheme.get_default()
> ^
>AttributeError: type object 'IconTheme' has no attribute 'get_default'
making it unusable.
[ Impact ]
Unusable program.
[ Tests ]
Tried the patched program in stable (and also in unstable where I
started with applying the fix in a QA upload).
[ Risks ]
Small fix, just adding requirements on the versions of Gtk and
PangoCairo.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Add requirements in the Python code to the Gtk and PangoCairo versions.
[ Other info ]
Bug recently fixed in Unstable too. (I managed to miss to mention the
Closes: field in the unstable upload changelog though, but have taken
care of closing the bug properly after the unstable upload).
glogic_stable.debdiff
Description: Binary data
