Bug#1087291: ITS: iptstate
Source: iptstate Version: 2.2.7-0.1 Severity: important X-Debbugs-Cc: Chris Taylor , 533...@bugs.debian.org, Package Salvaging Team Hi I'm interested in salvaging your package iptstate, 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: - NMU - 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/iptstate [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) 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#1087287: ITP: golang-github-google-flatbuffers -- FlatBuffers: Memory Efficient Serialization Library
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-google-flatbuffers Version : 24.3.25-1 Upstream Author : Google * URL : https://github.com/google/flatbuffers * License : Apache-2.0 Programming Lang: Go Description : FlatBuffers: Memory Efficient Serialization Library FlatBuffers is a cross platform serialization library architected for maximum memory efficiency. It allows you to directly access serialized data without parsing/unpacking it first, while still having great forwards/backwards compatibility. . This is a dependency needed for updating badger to a newer upstream release.
Bug#1087283: RM: caddy [ppc64el] -- RoQA; badger removal on ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ca...@packages.debian.org Control: affects -1 + src:caddy Control: block 1087236 by -1 User: ftp.debian@packages.debian.org Usertags: remove Hello, I've requested ppc64el removal of badger binaries in #1087236 and thus also filing this removal request on caddy which transitively depends on badger. Please see #1087236 for further details. Regards, Andreas Henriksson
Bug#1087282: RM: garagemq [ppc64el] -- ROM; badger removal on ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: garag...@packages.debian.org Control: affects -1 + src:garagemq Control: block 1087236 by -1 User: ftp.debian@packages.debian.org Usertags: remove Hello, Please consider removing the ppc64el binaries of garagemq, since garagemq depends on badger which fails tests on ppc64el and if/when #1087236 is processed will have its binaries removed. See #1087236 for further details. Regards, Andreas Henriksson
Bug#1087270: lollypop: small trouble with its main SQLite database?
On Sun, 10 Nov 2024 14:23:54 +0100 Patrice Duroux wrote: > Source: lollypop > Version: 1.4.40-1 > Severity: minor > > Hi, > > Today, lollypop refuse to start with the following error: > Traceback (most recent call last): 8< > > The lollypop.db seems not be recognized as a SQLite 3.x database any more. > I did not remember any issue with my desktop session since. > Could this be the effect of some recent library upgrades? > In the python stack? (last libsqlite3-0 update was in 2024-08-14) > Hmmm, that's really weird - I don't see these problems on my system, and I have an unstable which I update pretty much all the time. If you find no way to start lollypop, I would probably try to simply remove the database (the lollypop .db file) - as you probably know this is just a database for Lollypop, and it doesn't include the actual music, which is in files of their own, so it should be safe to remove it, and then regenerate it. /Andreas gus...@debian.org
Bug#1086937: pfstools: build against imagemagick 7
On 2024-11-09 Andreas Metzler wrote: [...] > And afaict this looks like a either a bug in cmake-data 3.30.5-1 or the > imagemagick 7 debian package uses different paths than cmake's > /usr/share/cmake-3.30/Modules/FindImageMagick.cmake expects. [...] Hello, Apart from that there is another issue with src/fileformat/pfsinimgmagick.cpp but Fedora already has a patch for that. cu Andreas
Bug#1087233: cmake-data: FindImageMagick.cmake fails to locate arch-specific include dir
On 2024-11-10 Andreas Metzler wrote: [...] > pfstools uses cmakes FindImageMagick.cmake as > find_package(ImageMagick COMPONENTS Magick++ MagickCore) > With imagemagick 7 magick-baseconfig.h was moved from > /usr/include/x86_64-linux-gnu/ImageMagick-6/magick/magick-baseconfig.h > to > /usr/include/x86_64-linux-gnu/ImageMagick-7/MagickCore/magick-baseconfig.h > and FindImageMagick.cmake only looks in magick/ not in MagickCore/. Changing FindImageMagick.cmake to also search in MagickCore/ works for me. -NAMES magick/magick-baseconfig.h +NAMES magick/magick-baseconfig.h MagickCore/magick-baseconfig.h 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#1087236: RM: badger [ppc64el] -- ROM; unresolved ppc64el specific bugs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: bad...@packages.debian.org Control: affects -1 + src:badger User: ftp.debian@packages.debian.org Usertags: remove Hello! Please consider if we can make a ppc64el specific binaries removal to get badger (and more importantly its reverse dependency caddy) back into testing. The binary packages build by badger are: * badger * golang-github-dgraph-io-badger-dev Badger is affected by (currently RC) bug #1078496 which is a ppc64el specific (spurious) test failure. It has also been reproduced and reported upstream: https://github.com/dgraph-io/badger/issues/2079 Apparently the interest in looking into this is close to non-existant. I assume the actual bug has existed forever and was just not caught by the tests until recently. I personally don't have ppc64el specific knowledge and/or time/interest to invest in adressing this. The alternative would be to disable tests (on ppc64el), which I find would be a worse solution than not providing the binary packages on this arch until someone shows interest. Please advice if I also need to file separate ppc64el removal bugs for: * garagemq (direct rdep) * caddy (indirect rdep) I assume these arch:all are not affected: * golang-github-smallstep-nosql * golang-github-smallstep-certificates Regards, Andreas Henriksson
Bug#998788: crack-attack uploaded to delayed=10
Hi, as per ITS bug I have uploaded crack-attack to delayed=10 queue. Kind regards Andreas. -- https://fam-tille.de
Bug#1087233: cmake-data: FindImageMagick.cmake fails to locate arch-specific include dir
Package: cmake-data Version: 3.30.5-1 Severity: serious Justification: 5 X-Debbugs-Cc: imagemag...@packages.debian.org, pfsto...@packages.debian.org Affects: pfstools Control: block 1086937 by -1 Good morning, pfstools FTBFS against imagemagick 7 (apt-get build-dep pfstools; apt-get install libmagick++-7.q16-dev libmagickcore-6-arch-config- ) In file included from /usr/include/ImageMagick-7/Magick++/Include.h:16, from /usr/include/ImageMagick-7/Magick++.h:12, from /tmp/PFSTOOLS/pfstools/src/fileformat/pfsinimgmagick.cpp:3 0: /usr/include/ImageMagick-7/MagickCore/magick-config.h:25:10: fatal error: Magick Core/magick-baseconfig.h: No such file or directory 25 | #include "MagickCore/magick-baseconfig.h" | ^~~~ [...] pfstools uses cmakes FindImageMagick.cmake as find_package(ImageMagick COMPONENTS Magick++ MagickCore) With imagemagick 7 magick-baseconfig.h was moved from /usr/include/x86_64-linux-gnu/ImageMagick-6/magick/magick-baseconfig.h to /usr/include/x86_64-linux-gnu/ImageMagick-7/MagickCore/magick-baseconfig.h and FindImageMagick.cmake only looks in magick/ not in MagickCore/. cu Andreas
Bug#1086937: pfstools: build against imagemagick 7
On 2024-11-07 po...@debian.org wrote: > Source: pfstools > Severity: serious > Hi, > pfstools is still built against imagemagick 6, but we're transitioning > to imagemagick 7, see [1]. > Your package may be build-depending on imagemagick 6 binaries (e.g. > libmagickwand-6.q16-dev), in which case it should switch to the new > binary packages, or generic ones if possible. > If your package build-depends on unversioned packages (e.g. > libmagick++-dev) then most likely it failed to build against the > new version, and will need fixes for ImageMagick 7. See the buildd > status for logs [2]. [...] Hello Emilio, pfstools FTBFS against imagemagick 7 with In file included from /usr/include/ImageMagick-7/Magick++/Include.h:16, from /usr/include/ImageMagick-7/Magick++.h:12, from /tmp/PFSTOOLS/pfstools/src/fileformat/pfsinimgmagick.cpp:3 0: /usr/include/ImageMagick-7/MagickCore/magick-config.h:25:10: fatal error: Magick Core/magick-baseconfig.h: No such file or directory 25 | #include "MagickCore/magick-baseconfig.h" | ^~~~ And afaict this looks like a either a bug in cmake-data 3.30.5-1 or the imagemagick 7 debian package uses different paths than cmake's /usr/share/cmake-3.30/Modules/FindImageMagick.cmake expects. The issue is that find_package(ImageMagick COMPONENTS Magick++ MagickCore) fails to locate "the ImageMagick arch-specific include dir" with v7. Using cmake -Wdev --log-level=TRACE --log-context --debug-find we find: -- CMake Debug Log at /usr/share/cmake-3.30/Modules/FindImageMagick.cmake:131 (find_path): find_path called with the following settings: VAR: ImageMagick_Magick++_ARCH_INCLUDE_DIR NAMES: "magick/magick-baseconfig.h" Documentation: Path to the ImageMagick arch-specific include dir. Framework Only Search Frameworks: 0 Search Frameworks Last: 0 Search Frameworks First: 0 AppBundle Only Search AppBundle: 0 Search AppBundle Last: 0 Search AppBundle First: 0 NO_DEFAULT_PATH Enabled find_path considered the following locations: /usr/include/ImageMagick-7/ImageMagick/magick/magick-baseconfig.h /usr/include/ImageMagick-7/ImageMagick-6/magick/magick-baseconfig.h /usr/include/ImageMagick-7/ImageMagick-7/magick/magick-baseconfig.h /usr/include/ImageMagick-7/magick/magick-baseconfig.h /usr/include/x86_64-linux-gnu/ImageMagick-7/ImageMagick/magick/magick-baseconfig.h /usr/include/x86_64-linux-gnu/ImageMagick-7/ImageMagick-6/magick/magick-baseconfig.h /usr/include/x86_64-linux-gnu/ImageMagick-7/ImageMagick-7/magick/magick-baseconfig.h /usr/include/x86_64-linux-gnu/ImageMagick-7/magick/magick-baseconfig.h The item was not found. -- With imagemagick 7 magick-baseconfig.h was moved from /usr/include/x86_64-linux-gnu/ImageMagick-6/magick/magick-baseconfig.h to /usr/include/x86_64-linux-gnu/ImageMagick-7/MagickCore/magick-baseconfig.h and FindImageMagick.cmake only looks in magick/ not in MagickCore/. cu Andreas
Bug#1075979: [Help] molds: FTBFS with mpich as default MPI provider: /usr/bin/ld: cannot find -lmpi_cxx: No such file or directory
Control: tags -1 - help Control: tags -1 pending Thanks Am Fri, Nov 08, 2024 at 09:11:51PM +0100 schrieb Drew Parsons: > We're in the middle of transitioning to OpenMPI 5. OpenMPI 5 removed > libmpi_cxx, which is why this bug happened. > > Bill is certainly right, -lstdc++ -lmpi -lmpi_cxx should not be hardcoded in > build rules. > and just using mpicxx is the simplest method. Thanks to you and Bill for the helpful hints. > But Build-Depends: libopenmpi-dev is also wrong, unless the program is badly > written and not conformant with the MPI standard. openmpi 5 does not build > on 32-bit arches, so we use mpich. > > Build-Depends: mpi-default-dev is the correct dependency > (alongside removing the hardcoded -lmpi -lmpi_cxx and using CXX=mpicxx) Thank you for clarifying this. Kind regards Andreas. -- https://fam-tille.de
Bug#932784: Done: Bug#932784: gdebi warning in buster
On Sat, 2 Nov 2024 15:10:29 +0100 =?utf-8?B?0L3QsNCx?= wrote: > Version: 0.9.5.7+nmu9 > > Per webview: > Marked as fixed in versions gdebi/0.9.5.7+nmu9. Request was from > Andreas Rönnquist to cont...@bugs.debian.org. (Tue, > 24 Sep 2024 14:33:01 GMT) (full text, mbox, link). > which matches > commit ad4160f696d852a92bf4be6f83f1500e1d84162f > Author: Andreas Rönnquist > Date: Tue Sep 10 01:03:23 2024 +0200 > > Fix findall command (Closes: #1076721, #926633) > > But didn't get closed. But it shouldn't have been closed - the bug is still affecting the versions in bullseye and bookworm, no? /Andreas Rönnquist gus...@debian.org
Bug#1086290: Bug#695178: fixed in psutils 1.17.dfsg-5
Hi, Am Thu, Nov 07, 2024 at 08:34:47AM +0100 schrieb Petter Reinholdtsen: > I suspect this fix to psnup caused the build problem in > https://bugs.debian.org/1086290 >. Do not know how or how to > fix it. > > The Makefile code in question is generated by Doxygen, so not straight > forward to fix in log4c. The only immediate fix for the FTBFS in log4c I can imagine would be to revert the patch for psutils. If you agree I can easily do so ... or you can do it as well since finally the package is in debian/ team space. Kind regards Andreas. -- https://fam-tille.de
Bug#1075979: [Help] molds: FTBFS with mpich as default MPI provider: /usr/bin/ld: cannot find -lmpi_cxx: No such file or directory
Control: tags -1 help Thanks Hi, today molds (from Debichem team) came up as candidate for the Bug of the Day[1]. I considered bug #1075979 easy to fix by simply adding libopenmpi-dev to Build-Depends since $ apt-file search libmpi_cxx.so | grep -- -dev libopenmpi-dev: /usr/lib/x86_64-linux-gnu/libmpi_cxx.so libopenmpi-dev: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so but this is obviously not the case for the 5.x series of libopenmpi-dev which does not contain this library any more. Any hints for replacements or other ways to make the linker happy are welcome since the problem remains. Thank you for any help Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks -- https://fam-tille.de
Bug#1086803: Bug#1075291: [patch, pending] mpg321: ftbfs with GCC-14
Hi Andreas,
Am Thu, Nov 07, 2024 at 07:32:52PM +0100 schrieb Andreas Metzler:
> > Well, my motivation was a popcon (vote!) > 100 to think there are some
> > users. I'm aware that upstream is dead but we have other packages
> > with dead upstream in Debian with way less users (and way more effort
> > to fix some RC bug).
>
> well, other similar pieces of software are not that easy to replace. ;-)
ACK.
> > I perfectly get your point but I'd prefer some soft migration for the
> > users. For instance we might write down those alternatives inside
> > README.Debian (which would you recommend). We could even try some
> > NEWS.Debian warning users that this is dead and recommend something
> > else.
>
> I think you have a very fair chance that less than 1 of 10 users
> would take a peek into README.Debian on a whim.
ACK as well (unfortunately).
> NEWS.Debian will be seen more often.
>
> But still this approach ("Drag it through another stable release just to
> show a message") is not sustainable for dealing with removal. We just
> drop them and expect people to deal with obsolete packages as described
> in the release notes
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#obsolete
Well, I'm actually not keen on putting even more packages on my table.
If you consider it better to remove that package I'm fine with this.
I've put the ITS bug in CC - if you want to reassign it to ftpmaster and
retitle to RoQA this might be a sensible procedure.
> You might wonder why I picked the whole thing up: During the usr-merge
> transition I also regularily looked at the rc bug list and also stumbled
> over mpg321. ATM I thought it would be better to drop it and filed bugs
> against all rdeps to switch to mpg123 (or whatever they preferred).
On the other hand we could upload the current packaging in Git to not
affect rdepends that have not yet switched and remove once all moved
away. To make things very clear: I do not insist in keeping everything
inside Debian - so removals are fine. However, as long as we have
something in Debian (even temporary) I prefer to have them in a good
shape.
Thanks a lot for your hints
Andreas.
--
https://fam-tille.de
Bug#1075291: [patch, pending] mpg321: ftbfs with GCC-14
On 2024-11-06 Andreas Tille wrote:
> Am Wed, Nov 06, 2024 at 06:40:41PM +0100 schrieb Andreas Metzler:
>> Are you really convinced we would not be better off dropping this
>> from Debian instead? mpg321 is stone-dead upstream (last commit about 12
>> years ago), alternatives with active upstream exist and are packaged.
> Well, my motivation was a popcon (vote!) > 100 to think there are some
> users. I'm aware that upstream is dead but we have other packages
> with dead upstream in Debian with way less users (and way more effort
> to fix some RC bug).
Hello Andreas,
well, other similar pieces of software are not that easy to replace. ;-)
> I perfectly get your point but I'd prefer some soft migration for the
> users. For instance we might write down those alternatives inside
> README.Debian (which would you recommend). We could even try some
> NEWS.Debian warning users that this is dead and recommend something
> else.
I think you have a very fair chance that less than 1 of 10 users
would take a peek into README.Debian on a whim. NEWS.Debian will be
seen more often.
But still this approach ("Drag it through another stable release just to
show a message") is not sustainable for dealing with removal. We just
drop them and expect people to deal with obsolete packages as described
in the release notes
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#obsolete
You might wonder why I picked the whole thing up: During the usr-merge
transition I also regularily looked at the rc bug list and also stumbled
over mpg321. ATM I thought it would be better to drop it and filed bugs
against all rdeps to switch to mpg123 (or whatever they preferred).
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#1081027: src:sssd: flaky autopkgtest: spawn id exp3 not open
Is d/t/ldap-user-group-krb5-auth also flaky? Because it uses the same
expect script:
d/t/ldap-user-group-krb5-auth:
...
# tests begin here
run_common_tests
# login works with the kerberos password
echo "The Kerberos principal can login on a terminal"
kdestroy > /dev/null 2>&1 || /bin/true
/usr/bin/expect -f debian/tests/login.exp "${ldap_user}"
"${kerberos_principal_pw}" "${ldap_user}"@"${myrealm}"
d/t/ldap-user-group-ldap-auth:
...
# tests begin here
run_common_tests
echo "The LDAP user can login on a terminal"
/usr/bin/expect -f debian/tests/login.exp "${ldap_user}" "${ldap_user_pw}"
On Wed, Nov 6, 2024 at 4:00 PM Paul Gevers wrote:
>
> Hi
>
> On 06-11-2024 07:43, Michael Prokop wrote:
> > Paul, do you know what could be the best option to reproduce the
> > behavior of https://ci.debian.net/ (locally)? Because the problem
> > seems to be environment specific, no one seems to have been able to
> > reproduce it on salsa so far. :-/
>
> As reported, it's flaky. Which means it might very well be only
> occurring under heavy load, or when specific other things are happening
> on the system. E.g. on i386, where only one debci worker runs per host,
> it seems to be much less flaky than on the other hosts where we run
> multiple (up to 18 on amd64) debci workers per host. You could try to
> spot patterns by matching timestamps of passing and failing tests to the
> historical performance [1].
>
> > Or what would be the best option to ignore this for now until it has
> > been tracked down, mark the test as flaky?
>
> It looks like each autopkgtest stanza has only one test, so yes, marking
> it flaky will resolve the problem (but also make the test close to
> worthless). (If on the contrary it's part of a whole test suite, you'd
> rather want to only mark the particular test as flaky or disable it, and
> not mark the autopkgtest stanza as flaky).
>
> Paul
>
> [1] https://ci.debian.net/munin/
>
Bug#1086915: Moved to Debian Phototools team (Was: ITS: mtpaint)
Hi, наб agreed with me that the package is better maintained by the Debian Phototools team. Thus I moved the repository to that team space[1]. I've also sent an invitation to you to maintain the package there. Kind regards Andreas. [1] https://salsa.debian.org/debian-phototools-team/mtpaint/ -- https://fam-tille.de
Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?
Hi, Am Thu, Nov 07, 2024 at 11:41:28AM +0100 schrieb Guillem Jover: > Ah I assumed the sources were being taken from pypi, if they are taken > from GitHub, then that explains yes. Perhaps using > https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan > is happy with that one), would solve that problem? (And if it does, > then perhaps python packages should be progressively transitioned to > use pypi URLs to avoid this kind of problem?) I have *not* inspected the situation personally. However, you might want to check the difference between the PyPI tarball and the tarball from Github. In lots of cases these are different and the maintainer might have picked Github for a reason (which is actually the recommendation I've read several times on the Debian Python list). Common cases are missing test suite inside PyPI tarball but maybe other things as well. > But I'm thinking that, perhaps the best option is to ask upstream > directly, whether they are going to release a 2.1.x release soon, or > if they could do that now, and/or whether they could perhaps > remove/rename the git tag perhaps (with the implied issues with messing > with history and git tags being sticky on cloned repos)? As I assume > other downstreams might be in the same/similar situation? Sounds sensible - otherwise I'd probably go with the override proposed by Colin. Kind regards Andreas. -- https://fam-tille.de
Bug#1081235: gdebi: Migrate packaging repository to git?
On Sat, 2 Nov 2024 14:21:58 +0100 =?utf-8?B?0L3QsNCx?= wrote: > On Tue, Sep 10, 2024 at 01:15:14AM +0200, Andreas Rönnquist wrote: > > On Mon, 9 Sep 2024 22:00:07 +0200 Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?= > > wrote: > > > 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. > The upstream is already in git. The bazaar says > 492. By Michael Vogt on 2015-07-08:releasing package gdebi version > 0.9.5.7 > 493. By Benjamin Drung on 2022-11-02:Move to > https://code.launchpad.net/~gdebi-developers/gdebi/+git/main > and https://code.launchpad.net/~gdebi-developers/gdebi/+git/main > has an accurate history of everything imported from bazaar. > > > "Proof of concept" available at > > https://salsa.debian.org/gusnan/gdebi > This appears to actually /be/ a fork (continuation) > of the repository above (SHAs match). > > Given that the old upstream is all but dead with open applications to > the gdebi-developers launchpad team since at least 2020, > and that development continues under collab-maint > (spelled as an NMU, but same difference), > we're just an ITS and updating Vcs-* fields away from making this official. > > gdebi came up on BOTD today and I fixed a few bugs. > I'll open an ITS and rebase my bugs on top of the new git repository. > The issue of the nominal maintainer post-salvage remains. > Hi! Yeah, I have done some work on it and closed some bugs - and the migration to the git repository - I wouldn't mind at all if that work was being used in any way, but since I did that I discovered that Mint (which I believe was driving the work behind gdebi at least to some extent) will go another way. (see "Maintaining better APT libraries and utilities" on https://blog.linuxmint.com/?p=4740 So, I doubt that they will use gdebi, and then I guess that Debian will follow that. But I don't know for sure of course, but one thing is clear to me at least - Mint will use other tools than gdebi. So before doing more work on this I would like to see which way those groups go, and don't waste more of my time on tools that won't get any usage anyway. More info in the two RFS's for the Mint tools Captain and aptkit which seems to be straight replacements of gdebi: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081743 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081742 /Andreas gus...@debian.org andr...@ronnquist.net
Bug#924980: Updating the libauthen-ntlm-perl Uploaders list
Hi Perl team,
the package libauthen-ntlm-perl became a candidate for the Bug of the
Day[1] since it had no Maintainer upload since >5 years, has a bug and
is not on Salsa - at least not visible for the users since Vcs-fields
are pointing to Alioth and the redirect is not working (any more).
I wonder if some of your team could be added as Uploader and the package
could be uploaded (possibly after updating to latest packaging
standards).
Kind regards
Andreas.
[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
--
https://fam-tille.de
Bug#1075291: [patch, pending] mpg321: ftbfs with GCC-14
Hi Andreas, Am Wed, Nov 06, 2024 at 06:40:41PM +0100 schrieb Andreas Metzler: > Are you really convinced we would not be better off dropping this > from Debian instead? mpg321 is stone-dead upstream (last commit about 12 > years ago), alternatives with active upstream exist and are packaged. Well, my motivation was a popcon (vote!) > 100 to think there are some users. I'm aware that upstream is dead but we have other packages with dead upstream in Debian with way less users (and way more effort to fix some RC bug). I perfectly get your point but I'd prefer some soft migration for the users. For instance we might write down those alternatives inside README.Debian (which would you recommend). We could even try some NEWS.Debian warning users that this is dead and recommend something else. Thanks a lot for your comment Andreas. -- https://fam-tille.de
Bug#1018121: fotoxx: depends on unmaintained clutter-1.0 and related libraries
Hi Michael, Am Wed, Nov 06, 2024 at 07:31:04AM +0100 schrieb Michael Cornelison: > Thanks for your message and esp. for your project to update fotocx. You are welcome. > Getting rid of clutter means a rewrite using GTK4. > This is a multi-month or year's project. Most probably. > If I do this, I will look for an alternative widget system not Gnome based. That's perfectly your choice. I simply wanted to do my duty to forward the issue upstream. I have no good technical recommendation for you. Kind regards Andreas. > On Tue, Nov 5, 2024 at 6:22 PM Andreas Tille wrote: > > > Control: tags -1 upstream > > Control: Michael Cornelison , Michael Cornelison < > > mkorne...@gmail.com> > > Thanks > > > > Hi Michael, > > > > there is a bug report[1] against the Debian packaged version of fotocx. > > Well, unfortunately the package was not updated for a long time so its > > the old fotoxx, but I intend to upgrade the package to its latest > > version. I verified that the dependency from clutter exists even in > > fotocx version 24.70. > > > > The bug report basically links to a document "Port apps away from > > clutter / cogl"[2] which might be potentially helpful for future > > versions of your nice program. > > > > Thanks a lot for providing fotocx as free software > > Andreas. > > > > [1] https://bugs.debian.org/1018121 > > [2] https://gitlab.gnome.org/GNOME/Initiatives/-/issues/31 > > > > -- > > https://fam-tille.de > > > > > -- > Mike > kornelix.net open source Linux apps > substack <https://michaelcornelison.substack.com/> essays -- https://fam-tille.de
Bug#1086869: ITS: proxy-suite
Source: proxy-suite Version: 1.9.2.4-10.1 Severity: important X-Debbugs-Cc: 928...@bugs.debian.org, 1039...@bugs.debian.org, 1066...@bugs.debian.org, Roberto Lumbreras , Package Salvaging Team Hi I'm interested in salvaging your package proxy-suite, 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: - NMU (last maintainer upload 10 years ago) - 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/proxy-suite [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.11.5-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#1075291: [patch, pending] mpg321: ftbfs with GCC-14
On 2024-11-06 Andreas Tille wrote: > Control: tags -1 patch > Control: tags -1 pending > Thanks > Hi, > this package came up as a candidate for the Bug of the Week[1]. > I've commited a patch[2] for this bug and will file an ITS bug > soon to get permission to maintain this package in Debian > Multimedia team. Once the ITS bug will be accepted or the waiting > time is over I intend to upload this package. Hello Andreas, Are you really convinced we would not be better off dropping this from Debian instead? mpg321 is stone-dead upstream (last commit about 12 years ago), alternatives with active upstream exist and are packaged. cu Andreas
Bug#1058364: python-etcd: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi, thanks a lot. BTW, since the package is team maintained you can always feel free to do a team upload. Kind regards and thanks again for your very welcome help Andreas. -- https://fam-tille.de
Bug#1086806: RM: php-sabre-event -- RoQA; Two RC bugs since 2017 unanswered
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: php-sabre-ev...@packages.debian.org, 851...@bugs.debian.org, 882...@bugs.debian.org, Debian PHP PEAR Maintainers , pkg-owncloud-maintain...@lists.alioth.debian.org, David Prévot , Package Salvaging Team Control: affects -1 + src:php-sabre-event User: ftp.debian@packages.debian.org Usertags: remove Hi, php-sabre-event showed up today as candidate for the Bug of the Day[1]. I realised it has two RC bugs without response from the maintainer since 2017. This seems to be a significant sign that the package can be removed from Debian. Kind regards and thank you for your work as ftpmaster Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
Bug#1086810: ITS: xtermset
Source: xtermset Version: 0.5.2-6 Severity: important X-Debbugs-Cc: 1046...@bugs.debian.org, Chrysostomos Nanakos , Package Salvaging Team Hi I admit the current issues in your package xtermset are not severe and its not really in need of salvaging. The package might be in need for some love anyway after it came up as some candidate for the Bug of the Day[1] I've spent some time into it, to modernise the packaging, fix some links and also the clean target (#1046810). 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/ (given xtermset was once in collab-maint SVN on Alioth which I importet into the packaging Git repository on Salsa) this might be your prefered location. I was also wondering whether I should simply go on with a "Debian Team upload" but I've thought asking you via the ITS formalism might be the better way to ask for your confirmation. As said above your package was highlighted in the Bug of the Day[1] 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://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/xtermset [3] svn://anonscm.debian.org/collab-maint/ext-maint/xtermset/trunk -- 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.11.5-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#761879: fotoxx: Insecure use of temporary files
Hi Michael, Am Wed, Nov 06, 2024 at 09:51:12AM +0100 schrieb Michael Cornelison: > Thanks again. You are welcome. > Re: detect root user and exit() if root. > > I do not want to make a new release now, but I will add this in the next > release, planned for Jan 1 or so. > I hope this is OK. This is perfectly fine. Thanks a lot for your really quick responses Andreas. -- https://fam-tille.de
Bug#1085867: Try harder to merge
Control: severity 1085867 normal Control: retitle 1085867 RM: php-sabre-event -- RoM; rc-buggy Control: reassign 1085867 ftp.debian.org Control: affects 1085867 + src:php-sabre-event Control: affects 1086806 + src:php-sabre-event Control: merge 1085867 1086806 Thanks
Bug#1085867: Merge
Control: merge 1086806 1085867 Thanks
Bug#1086803: ITS: mpg321
Source: mpg321 Version: 0.3.2-3.3 Severity: important X-Debbugs-Cc: 687...@bugs.debian.org, 728...@bugs.debian.org, 864...@bugs.debian.org, 1075...@bugs.debian.org, Debian Multimedia Maintainers , Nanakos Chrysostomos , Package Salvaging Team Hi I'm interested in salvaging your package FIXME, 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 - specifically a FTBFS RC bug which I fixed in Git and tagged pending upload I believe your package would be a great addition to the Debian Multimedia team, and I'm planning to create 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/mpg321 [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.11.5-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#306989: [upstream] does not work in a UTF-8 locale
Control: tags -1 upstream Control: forwarded -1 https://github.com/jomael/mpg321/issues/3
Bug#761879: fotoxx: Insecure use of temporary files
Hi Michael, Am Wed, Nov 06, 2024 at 07:49:41AM +0100 schrieb Michael Cornelison: > 'wprintp' function no longer exists. > > 'email_dialog_event' function no longer exists. > > file "/tmp/global_lock_fotoxx_syncfiles" no longer exists. > > The bug report says that using fotoxx as root user is necessary to trigger > this bug. I *personally* admit its the users own fault to use fotoxx as root, but well ... > In fact, using fotoxx (now fotocx) as root user can do many things to crash > or alter a running system or alter files belonging to root. What is the fix > for this? I could detect if running as root user and just exit. Is that a > fix? In my eyes this is a fix, yes. Thanks a lot for the quick response Andreas. > On Tue, Nov 5, 2024 at 6:27 PM Andreas Tille wrote: > > > Control: tags -1 upstream > > Control: forwarded -1 Michael Cornelison > > Thanks > > > > Hi Michael, > > > > there is a ten year old bug report[1] against the fotoxx code that was > > uploaded to Debian at that time. I intend to close this bug in my next > > upload but I would like to get your confirmation that the problem is > > dealt with in your current code. Please be so kind to have a look[1] > > since the issue is potentially security relevant. > > > > Kind regards and thank you for providing fotocx as free software > >Andreas. > > > > [1] https://bugs.debian.org/761879 > > > > -- > > https://fam-tille.de > > > > > -- > Mike > kornelix.net open source Linux apps > substack <https://michaelcornelison.substack.com/> essays -- https://fam-tille.de
Bug#1075291: [patch, pending] mpg321: ftbfs with GCC-14
Control: tags -1 patch Control: tags -1 pending Thanks Hi, this package came up as a candidate for the Bug of the Week[1]. I've commited a patch[2] for this bug and will file an ITS bug soon to get permission to maintain this package in Debian Multimedia team. Once the ITS bug will be accepted or the waiting time is over I intend to upload this package. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/multimedia-team/mpg321/-/blob/master/debian/patches/gcc-14.patch?ref_type=heads -- https://fam-tille.de
Bug#1086777: ITS: le
Source: le Version: 1.16.8-0.1 Severity: important X-Debbugs-Cc: 969...@bugs.debian.org, Raphael Geissert , Package Salvaging Team Hi I'm interested in salvaging your package le, 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: - NMU - 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. (except in NMU) - 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/le [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.11.5-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#1081027: src:sssd: flaky autopkgtest: spawn id exp3 not open
It passed[1] in salsa: + /usr/bin/expect -f debian/tests/login.exp testuser1 testuser1secret The LDAP user can login on a terminal spawn login ldap login: testuser1 Password: Linux ldap.example.com 5.10.0-33-cloud-amd64 #1 SMP Debian 5.10.226-1 (2024-10-03) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Creating directory '/home/testuser1'. testuser1@ldap:~$ id -un testuser1 testuser1@ldap:~$ + cleanup + result=0 + set +e + [ 0 -ne 0 ] + echo ## All tests passed, phew ## All tests passed, phew autopkgtest [18:02:28]: test ldap-user-group-ldap-auth: ---] Perhaps we could remove the "set -x"? I wonder if it could interfere sometimes. 1. https://salsa.debian.org/ahasenack/sssd/-/jobs/6539986/viewer#L801 On Tue, Nov 5, 2024 at 2:38 PM Andreas Hasenack wrote: > > I wrote that test initially, and it has been passing in Ubuntu. Sounds > like it's some difference in the infrastructure. > > I tried locally in a debian LXD container, and it passed just fine. Is > it also failing in salsa pipeline runners, or just in the migration by > britney? > > The error seems to indicate that "login" died, or wasn't ready: > > 105s + /usr/bin/expect -f debian/tests/login.exp testuser1 > testuser1kerberos testus...@example.com > 105s spawn login > 105s send: spawn id exp3 not open > 105s while executing > 105s "send "$user\r"" > 105s (file "debian/tests/login.exp" line 21) > 105s autopkgtest [18:34:46]: test ldap-user-group-krb5-auth: > ---] > > These timestamps don't seem to indicate when it happened, but when the > log dump happened, right? Otherwise it all happened at 105s basically. > > If this failure also happens in salsa, then we can inject some > debugging into the test in the case of failures. I don't know if I > have permissions to trigger a pipeline run in salsa, I'll try with an > MP. > > On Tue, Nov 5, 2024 at 3:57 AM Michael Prokop wrote: > > > > Hi, > > > > * Paul Gevers [Sat Sep 07, 2024 at 07:13:21AM +0200]: > > > > > I looked at the results of the autopkgtest of your package. I noticed that > > > it regularly fails. > > > > > > Because the unstable-to-testing migration software now blocks on > > > regressions in testing, flaky tests, i.e. tests that flip between > > > passing and failing without changes to the list of installed packages, > > > are causing people unrelated to your package to spend time on these > > > tests. > > > > > > Don't hesitate to reach out if you need help and some more information > > > from our infrastructure. > > > > > > Paul > > > > > > https://ci.debian.net/packages/s/sssd/testing/amd64/51295873/ > > > > > > 41s The LDAP user can login on a terminal > > > 41s + /usr/bin/expect -f debian/tests/login.exp testuser1 testuser1secret > > > 41s spawn login > > > 41s send: spawn id exp3 not open > > > 41s while executing > > > 41s "send "$user\r"" > > > 41s (file "debian/tests/login.exp" line 21) > > > > I'm aware of folks looking into that, but AFAICT so far nobody was > > able to proberly reproduce the issue - so it feels like really being > > a flaky test? Should the ldap-user-group-ldap-auth test get marked > > as flaky for now, until someone managed to properly take care of > > this? > > > > IMO sssd needs to make its way into trixie. > > > > regards > > -mika-
Bug#1081027: src:sssd: flaky autopkgtest: spawn id exp3 not open
I wrote that test initially, and it has been passing in Ubuntu. Sounds like it's some difference in the infrastructure. I tried locally in a debian LXD container, and it passed just fine. Is it also failing in salsa pipeline runners, or just in the migration by britney? The error seems to indicate that "login" died, or wasn't ready: 105s + /usr/bin/expect -f debian/tests/login.exp testuser1 testuser1kerberos testus...@example.com 105s spawn login 105s send: spawn id exp3 not open 105s while executing 105s "send "$user\r"" 105s (file "debian/tests/login.exp" line 21) 105s autopkgtest [18:34:46]: test ldap-user-group-krb5-auth: ---] These timestamps don't seem to indicate when it happened, but when the log dump happened, right? Otherwise it all happened at 105s basically. If this failure also happens in salsa, then we can inject some debugging into the test in the case of failures. I don't know if I have permissions to trigger a pipeline run in salsa, I'll try with an MP. On Tue, Nov 5, 2024 at 3:57 AM Michael Prokop wrote: > > Hi, > > * Paul Gevers [Sat Sep 07, 2024 at 07:13:21AM +0200]: > > > I looked at the results of the autopkgtest of your package. I noticed that > > it regularly fails. > > > > Because the unstable-to-testing migration software now blocks on > > regressions in testing, flaky tests, i.e. tests that flip between > > passing and failing without changes to the list of installed packages, > > are causing people unrelated to your package to spend time on these > > tests. > > > > Don't hesitate to reach out if you need help and some more information > > from our infrastructure. > > > > Paul > > > > https://ci.debian.net/packages/s/sssd/testing/amd64/51295873/ > > > > 41s The LDAP user can login on a terminal > > 41s + /usr/bin/expect -f debian/tests/login.exp testuser1 testuser1secret > > 41s spawn login > > 41s send: spawn id exp3 not open > > 41s while executing > > 41s "send "$user\r"" > > 41s (file "debian/tests/login.exp" line 21) > > I'm aware of folks looking into that, but AFAICT so far nobody was > able to proberly reproduce the issue - so it feels like really being > a flaky test? Should the ldap-user-group-ldap-auth test get marked > as flaky for now, until someone managed to properly take care of > this? > > IMO sssd needs to make its way into trixie. > > regards > -mika-
Bug#761879: fotoxx: Insecure use of temporary files
Control: tags -1 upstream Control: forwarded -1 Michael Cornelison Thanks Hi Michael, there is a ten year old bug report[1] against the fotoxx code that was uploaded to Debian at that time. I intend to close this bug in my next upload but I would like to get your confirmation that the problem is dealt with in your current code. Please be so kind to have a look[1] since the issue is potentially security relevant. Kind regards and thank you for providing fotocx as free software Andreas. [1] https://bugs.debian.org/761879 -- https://fam-tille.de
Bug#1018121: fotoxx: depends on unmaintained clutter-1.0 and related libraries
Control: tags -1 upstream
Control: Michael Cornelison , Michael Cornelison
Thanks
Hi Michael,
there is a bug report[1] against the Debian packaged version of fotocx.
Well, unfortunately the package was not updated for a long time so its
the old fotoxx, but I intend to upgrade the package to its latest
version. I verified that the dependency from clutter exists even in
fotocx version 24.70.
The bug report basically links to a document "Port apps away from
clutter / cogl"[2] which might be potentially helpful for future
versions of your nice program.
Thanks a lot for providing fotocx as free software
Andreas.
[1] https://bugs.debian.org/1018121
[2] https://gitlab.gnome.org/GNOME/Initiatives/-/issues/31
--
https://fam-tille.de
Bug#1018290: Is it time for uploading (Was: ITS: tiny-initramfs)
Control: tags -1 pending Thanks Hi Victor, since tiny-initramfs today came up as candidate for the bug of the day[1] I had a look into it and found your ITS bug. Great! I think the waiting period is over and we can upload to delayed=10. I could easily do so but I wonder what maintainer you might have intended for the d/control Maintainer field. If you want to take over - just feel free to add your name (I personally would keep the former maintainer as Uploader). Otherwise we can put the Package Salvage team as Maintainer an I add you as Uploader. In any case I've updated the package in Git[2] and closed those bugs that had patches attached. From my point of view the package is ready to upload. Feel free to decide whether you want to do so or tell me if you prefer that I upload the current status of Git. Kind regards Andreas. PS: Greetings to Iceland - I need to come back urgently! ;-) [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/debian/tiny-initramfs -- https://fam-tille.de
Bug#1086760: ITS: farpd
Source: farpd Version: 0.2-11.4 Severity: important X-Debbugs-Cc: 542...@bugs.debian.org, 1039...@bugs.debian.org, Javier Fernández-Sanguino Peña , Package Salvaging Team Hi I'm interested in salvaging your package farpd, 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/farpd [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.11.5-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#1080956: SaunaFS
Am Mon, Nov 04, 2024 at 10:55:12PM +0530 schrieb Ananthu C V: > > I suggest using the `execute_before_dh_missing:` target instead of overriding > and then calling dh_missing again. Hopefully that works. This works definitely. I'm just using the old style since I never remember this more elegant way. ;-) Thank you for the hint Andreas. -- https://fam-tille.de
Bug#1000303: liboqs: not yet ready for testing or stable
On 2023-06-28 Andrius Merkys wrote: > On Wed, 28 Jun 2023, 10:09 Mikael Frykholm, wrote: >>> The upstream wishes to keep the package out of stable distributions for >>> now, until the NIST Post-Quantum Cryptography standardization project >>> reaches its conclusion >> Is this still true? Can this package be migrated to testing now? > The upstream has to be contacted regarding the status of liboqs. They have > previously explicitely expressed their wish to stay out of testing. Hello, I have asked on https://github.com/orgs/open-quantum-safe/discussions/1625#discussioncomment-11145285 for an update. 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#1086715: ITS: vorbisgain
Source: vorbisgain Version: 0.37-2.1 Severity: important X-Debbugs-Cc: 537...@bugs.debian.org, 698...@bugs.debian.org, 939...@bugs.debian.org, Daniel Martí , Package Salvaging Team Hi I'm interested in salvaging your package vorbisgain, 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 believe your package would be a great addition to the Debian Multimedia team, and I'm planning to create 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/vorbisgain [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.11-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#1080956: SaunaFS
Hi Urmas, Am Sun, Nov 03, 2024 at 10:43:19PM +0200 schrieb Urmas Rist: > Hello everyone! > > I've pushed the package source along with the upstream source > code to https://salsa.debian.org/hpc-team/saunafs/. I've mostly finished > up everything, fixing lintian issues, cleaning up various areas and > adding the uraft package which was missing from the lizardfs package > (due to the version when it was introduced was never released upstream > outside of release candidates). I was running `routine-update` on it which did some more enhancements specifically also debhelper compat level = 13. This changes dh_missing default from --list-missing to --fail-missing which breaks the build as you can see in Salsa CI (which I switched on): https://salsa.debian.org/hpc-team/saunafs/-/jobs/6533697 Since I have no idea whether those files that are part of the upstream install target but not made their way into one of the binary packages should be installed or not neither to which of the resulting binary packages. Please inspect the build log linked above. I would recommend to do override_dh_missing: rm -rf FILES YOU WANT TO REMOVE dh_missing (A simple `dh_missing --list-missing` would restore the previous build behaviour but I think its better to have some fine grained control.) > I've also almost tested everything outside the uraft package (for uraft > I only checked if the binaries work and service files exist) and it > seems to work well with a small setup on Debian sid. I personally do not know how to test the result. > I guess the question is now who would be willing to sponsor and review > this? Just ping here on this channel. Hope this helps Andreas. -- https://fam-tille.de
Bug#1086196: packeth should include GUI version
Hi,
thank you for your bug report. I agree that having the GUI version
which is somehow the default build of this package would be nice to
have. However, I have not seen this distributed in any previous version
of this package (admittedly I did not checked every single past
release). Could you please enlighten me to what package version you are
refering with "like the previous distribution had"?
The background of my question is that the binary for the CLI version
is renamed. I would like to keep the very same names as in the package
you were refering to.
Moreover I have some doubt that it is a good idea to provide both
binaries inside the same binary package. Probably its more sensible to
have some `packeth` and `packeth-gui` package since the latter would
come with some Dependencies a user of the CLI version might not want to
be installed.
Kind regards
Andreas.
--
https://fam-tille.de
Bug#1084085: tzc uploaded to delayed=10
Hi again, since I learned you were not happy with the upload of tzc I removed the package from the delayed queue. Feel free to profit from the repository https://salsa.debian.org/salvage-team/tzc for your own potential next upload. Please let me know if you want to take it over to some other place to let me remove the duplicate that might become outdated. Sorry for any inconvenience / misunderstanding I might have caused Andreas. Am Thu, Oct 31, 2024 at 04:58:21PM +0100 schrieb Andreas Tille: > Am Wed, Oct 30, 2024 at 05:11:09PM -0700 schrieb Theodore Ts'o: > > ... > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > This page lists the possible indicators: > > NMUs, especially if there has been more than one NMU in a row. > which is true > > Bugs filed against the package do not have answers from the maintainer. > well, it was the case for the single bug > > > > There is one outstanding bug before you filed the ITS bug, and it was > > a man page typo fix. This wasn't particularly urgent to fix, > > Perfectly true. Its absolutely not urgent. > > > and it > > seems odd to call that "poorly maintained". > > Four NMUs in a row might be an indication that the maintainer lost > interest. > > > So if you're not going to actively taking over maintainership, why are > > you initiating the salvaging process? > > I said: "I admit I have no personal interest in this package and I do > not use it." I maintain several packages which I'm not using. I'm > perfectly fine if you disagree with the attempt to salvage and I can > easily remove the upload to delayed. My intention was genuinely to lend > a helping hand, and I apologize sincerely if it wasn’t received as such. > Please let me know if it caused any inconvenience, and I’ll be more than > happy to undo the upload. > > Kind regards > Andreas. > > -- > https://fam-tille.de -- https://fam-tille.de
Bug#1086687: ITS: packeth
Hi David, thank you for the quick reply - happy to hear from you after many years! Would have loved to meet you in person if there is some chance Andreas. Am Sun, Nov 03, 2024 at 11:40:26PM +0100 schrieb David Paleino: > Hey Andreas! > (sorry for top-quoting, replying from my mobile) > > Please go ahead! > David > > > Il Dom 3 Nov 2024, 22:09 Andreas Tille ha scritto: > > > Source: packeth > > Version: 2.1-0.2 > > Severity: important > > X-Debbugs-Cc: 720...@bugs.debian.org, 1059...@bugs.debian.org, > > 1069...@bugs.debian.org, David Paleino , Package > > Salvaging Team > > > > Hi > > > > I'm interested in salvaging your package packeth, 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/packeth > > [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) > > 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 > > -- https://fam-tille.de
Bug#1086687: ITS: packeth
Source: packeth Version: 2.1-0.2 Severity: important X-Debbugs-Cc: 720...@bugs.debian.org, 1059...@bugs.debian.org, 1069...@bugs.debian.org, David Paleino , Package Salvaging Team Hi I'm interested in salvaging your package packeth, 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/packeth [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) 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#1086513: piuparts: wrong check (ERROR:) on missing files after dpkg-divert --no-rename
On 10/31/24 17:44, Lorenzo Puliti via Piuparts-devel wrote: Package: piuparts Version: 1.4.4 Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear piuparts maintainer, I'm going to use dpkg-divert on essential files with one of my package (runit-init); since files to be diverted are shipped by an essential package, I'm using '--no-rename' option. When the package is tested, piuparts ERROR with debsums: missing file /usr/sbin/invoke-rc.d.real (from init-system-helpers package) debsums: missing file /usr/sbin/service.real (from init-system-helpers package) debsums: missing file /usr/share/man/man8/invoke-rc.d.8.gz.real (from init-system-helpers package) debsums: missing file /usr/share/man/man8/service.8.gz.real (from init-system-helpers package) after runit-init (the package that adds the diversion) is removed, piuparts detects that, for example, /usr/sbin/invoke-rc.d.real should be there (but it's missing) when in fact is /usr/sbin/invoke-rc.d that should be there (and it's not missing). It's not piuparts detecting the error but debsums, piuparts just propagates it. I believe my package does it the right way, when it's removed it removes the diversion and it makes sure that diverted files are restored in their original location. I don't think so. The copying bits in the prerm belong to the preinst (when the "other" variant is still there), otherwise you copy (and restore) the "runit" variant. Can you reproduce this manually in a minimal chroot with debsums installed where you install init-system-helpers, install runit-init, remove runit-init? And frequently check with debsums -ac --ignore-obsolete Andreas
Bug#1084085: tzc uploaded to delayed=10
Am Wed, Oct 30, 2024 at 05:11:09PM -0700 schrieb Theodore Ts'o: > ... > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging This page lists the possible indicators: NMUs, especially if there has been more than one NMU in a row. which is true Bugs filed against the package do not have answers from the maintainer. well, it was the case for the single bug > There is one outstanding bug before you filed the ITS bug, and it was > a man page typo fix. This wasn't particularly urgent to fix, Perfectly true. Its absolutely not urgent. > and it > seems odd to call that "poorly maintained". Four NMUs in a row might be an indication that the maintainer lost interest. > So if you're not going to actively taking over maintainership, why are > you initiating the salvaging process? I said: "I admit I have no personal interest in this package and I do not use it." I maintain several packages which I'm not using. I'm perfectly fine if you disagree with the attempt to salvage and I can easily remove the upload to delayed. My intention was genuinely to lend a helping hand, and I apologize sincerely if it wasn’t received as such. Please let me know if it caused any inconvenience, and I’ll be more than happy to undo the upload. Kind regards Andreas. -- https://fam-tille.de
Bug#1084085: tzc uploaded to delayed=10
Hi Theodore, Am Mon, Oct 28, 2024 at 09:22:21PM -0700 schrieb Theodore Ts'o: > > as per ITS bug I have uploaded tzc to delayed=10. > > Do you have access to a Zephyr messaing system so you can test tzc? > And are you using the emacs zephyr-mode? Which might be a good idea > to package if we are going to keep tzc in Debian... I admit I have no personal interest in this package and I do not use it. My interest was to make some package that was NMUed a couple of times, and thus obviously gained some interest by several people, more easily accessible for potential contributors. Thus I filed the ITS bug. If you think its better to remove the package I'm perfectly fine with this. Just let me know if you prefer canceling the upload. Kind regards Andreas. -- https://fam-tille.de
Bug#1074921: [Tag pending] dsh: ftbfs with GCC-14
Control: tags -1 pending Control: block -1 by 1086438 Thanks Hi, the bug is fixed in Git[1]. The Package Salvage team is waiting for confirmation that the package can be team uploaded (ITS: #1086438) [1] https://salsa.debian.org/salvage-team/dsh -- https://fam-tille.de
Bug#1086438: ITS: dsh
Source: dsh Version: 0.25.10-1.6 Severity: important X-Debbugs-Cc: 1074...@bugs.debian.org, Junichi Uekawa , Package Salvaging Team Hi Junichi, I'm interested in salvaging your package dsh, 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/dsh [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.11-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#841434: Updating whohas to latest upstream commit?
Am Wed, Oct 30, 2024 at 09:50:58AM -0400 schrieb Yaroslav Halchenko:
> FWIW it is perfectly find with me. Thank you Andreas!
OK, uploaded (but currently we have quite some delay until it hits
unstable ...
Kind regards
Andreas.
--
https://fam-tille.de
Bug#1086004: ITS: perforate
Hi Reuben, Am Wed, Oct 30, 2024 at 10:06:10AM + schrieb Reuben Thomas: > > I've done this at https://salsa.debian.org/salvage-team/perforate already > > That's amazing, what is there left for me to do, then? I guess nothing for the moment. Thanks a lot for becoming involved anyway Andreas. -- https://fam-tille.de
Bug#841434: Updating whohas to latest upstream commit?
Control: tags -1 pending
Thanks
Hi Paul & Yaroslav,
whohas came up as candidate for the Bug of the Day[1] today. Thus I had
a look. I realised Paul has forwarded lots of patched to upstream Git
which are fixing bug #841434 ... and probably a lot of other nice
enhancements looking at the history of commits which are not yet turned
into some release.
Thus I decided to update the packaging to the latest upstream commit in
Salsa[2] by using the git API in d/watch. I have also modernised the
packaging to latest standards. I'd happily do a team upload on behalf
of the Debian team if this is OK for you.
Kind regards
Andreas.
[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
[2] https://salsa.debian.org/debian/whohas
--
https://fam-tille.de
Bug#634966: guifications uploaded to delayed=10
Control: tags -1 pending Thanks Hi Nick, as per ITS bug I have uploaded guifications to delayed=10. Kind regards Andreas. -- https://fam-tille.de
Bug#1086346: ITS: aspell-fr
Source: aspell-fr Version: 0.50-3-8.1 Severity: important X-Debbugs-Cc: 329...@bugs.debian.org, 257...@bugs.debian.org, Rémi Vanicat , Package Salvaging Team Hi I'm interested in salvaging your package aspell-fr, 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. A lot of aspell-LANG packages can be found inside the debian/ team space to enable cooperative maintenance. That's why I've 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, wherever you prefer. My goal is to make it as easy as possible for you to maintain your package on Salsa. 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/aspell-fr [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.11-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#1084788: Retitle: ITS: utfout
Control: ITS: utfout Control: severity -1 important Thanks Hi again, since I did not got any response to my kind request to migrate to some Git based workflow on Salsa I somehow assume this package might really not in your focus any more. Thus I retitle the bug to ITS and will at least apply the patch of bug #986379 in some ITS upload after 21 days. Kind regards Andreas. -- https://fam-tille.de
Bug#920175: Reassign + pending: typo in german Goethe aphorism
Control: reassign -1 fortunes-de
Control: tags -1 pending
Thanks
Hi,
thanks for reporting the typo. It should have been reported to
fortunes-de. Thus I'm reassigning the bug to this package. I've
also fixed the typo in Git of this package thus tagging it pending.
Kind regards
Andreas.
--
https://fam-tille.de
Bug#856384: [Moreinfo] fortune all fails to load any cookies
Control: tags -1 moreinfo Thanks Hi Jiri, thanks a lot for the patch I've tried it but it does not work for me. $ dpkg --get-selections | grep ^fortune fortune-mod install fortunes-de install Kind regards Andreas. -- https://fam-tille.de
Bug#796596: [Moreinfo] fortune: command not found
Control: tags -1 moreinfo Thanks Are you sure /usr/games is in your PATH? Kind regards Andreas. -- https://fam-tille.de
Bug#1086050: ITS: pcaputils
Hi Robert, Am Sun, Oct 27, 2024 at 01:16:45AM -0400 schrieb Robert Edmonds: > > If you're interested in taking over the pcaputils package, please feel > free. Uploaded. Thank you for confirming Andreas. > Looking at my archives I don't think I ever kept this package in version > control. So I would suggest either importing the archived versions of > the package [0] into a new Git repository or just starting from the > current revision in the archive. > > Separately, the upstream package is in rather poor shape, too, and it's > unlikely I'll be developing it further since I don't use of the > utilities any more. If you know anyone interested in taking over the > upstream maintainership as well I would be happy to hand it off, too. > > [0] https://snapshot.debian.org/package/pcaputils/ > > Thanks! > > -- > Robert Edmonds > edmo...@debian.org > -- https://fam-tille.de
Bug#1086192: ITS: fotoxx
Source: fotoxx Version: 20.08-2 Severity: important X-Debbugs-Cc: 1006...@bugs.debian.org, Santiago Torres Batan , Package Salvaging Team Hi I'm interested in salvaging your package fotoxx, 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. (actually upstream has renamed the package to fotocx[2] meanwhile) - There are QA issues with the package. I believe your package would be a great addition to the Debian Phototools Team - so I admit I would prefer moving it from debian/ team space to debian-phototools-team. My goal is to make it as easy as possible for you to join the team. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://kornelix.net/fotocx/fotocx.html -- 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.11-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#1086190: ITS: pydf
Source: pydf Version: 12+nmu1 Severity: important X-Debbugs-Cc: 851...@bugs.debian.org, 1082...@bugs.debian.org, Radovan Garabík , Package Salvaging Team Hi I'm interested in salvaging your package pydf, 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. BTW, I've opened an according issue on Github[4]. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://salsa.debian.org/salvage-team/pydf [3] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [4] https://github.com/garabik/pydf/issues/9 -- 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.11-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#773333: [wontfix] fonts-droid: droid sans fallback incorrectly displays CJK characters (too long)
Control: tags -1 wontfix Thanks Hi, fonts-droid is dead upstream so this will not be fixed any more. Please try using fonts-noto which is an improved version of Droid. Kind regards Andreas. -- https://fam-tille.de
Bug#816911: [wontfix] Should probably ship a transitional package fonts-droid to migrate to fonts-droid-fallback
Control: tags -1 wontfix Thanks. Hi, as Jonas explained and as it can be read in bug #859913 the situation does not permit some simple transitional package (since its not clear whether to transition to fonts-noto or fonts-droid-fallback. That's why I tag the bug wontfix. Kind regards Andreas. -- https://fam-tille.de
Bug#1086004: ITS: perforate
Hi Reuben, thank you for your very helpful hint! Am Sat, Oct 26, 2024 at 03:44:11PM +0100 schrieb Reuben Thomas: > On Thu, 24 Oct 2024 at 18:03, Andreas Tille wrote: > > > I'm interested in salvaging your package perforate, in accordance with > > the Package Salvaging procedure outlined in the Developers Reference[1]. > > That would be great! :-) > I have done quite a bit of work on this package that has not been released > in Debian, largely, I suspect, because it involves a name change. > > See https://github.com/rrthomas/finddup I guess you know perfectly why we (currently - I try to work on this) are keen on avoiding name changes. > The main points are that a) there was never a program called 'perforate', > b) the program 'zum' that did the "perforating" is now otiose, as file > systems and cp between them take care of this functionality, and so c) the > useful functionality left in the package was mainly the 'finddup' program, > which I have updated, along with the minor utility 'findstrip', and the > 'findcore' script which I've added to my version of the package. What do you consider the best way of action here? For the moment I wonder whether we keep the source+binary package name perforate (even if I confirm this name does not make much sense), point the watch file to your fork, and deliver finddup, findstrip and findcore inside the binary package perforate. The whole thing should be explained in NEWS.Debian. For sure we could also create a new package finddup and make it Conflicts/Provides: perforate. I would sponsor such a package to new. But please lets maintain the Debian packaging on Salsa (and the upstream code whereever it belongs). Kind regards and thanks again Andreas. -- https://fam-tille.de
Bug#484050: tzc uploaded to delayed=10
Control: tags -1 pending Thanks Hi, as per ITS bug I have uploaded tzc to delayed=10. Kind regards Andreas. -- https://fam-tille.de
Bug#1080956: SaunaFS
Hi Urmas, Am Sun, Oct 27, 2024 at 05:57:24PM +0200 schrieb Urmas Rist: > > The best idea to get help and reviews is to maintain the Debian > > packaging on https://salsa.debian.org. > > I've created an account, so now I'm awaiting approval. In the meantime, > I've looked at some other repositories and I'm wondering whether to push > the upstream code and the debian folder, or just the debian folder? I'd recommend the repository layout as described in Debian Med policy: https://med-team.pages.debian.net/policy/ Its designed following other teams and many teams in Debian do it this way. > I've > seen many repositories do the former, while for example LizardFS (which > this project forked) had the latter (although it has not been obviously > updated for a while). Its usually considered to have a copy of the upstream source inside the packaging repository. > > ...Its not really a bioinformatics > > packages but there is a Debian HPC team where it might be a good fit. > > Please let me know if you agree and I'll happily smoothen your way into > > this team. > > Awesome, please do if you can. Thank you for your help on this! Just let me know your Salsa login name. > > For several reasons Github is not the best place. There is > > mentors.debian.net but my personal sponsoring policy is that I sponsor > > from Salsa only since it enables me to do simple polising easily which > > is quite straightforward for the sponsee. > > > > But I should still register and upload the packaging/source to mentors > as well? Or is salsa enough? In Debian Med team we ignore mentors and you ping the list. It might be that Debian HPC is doing the same. I'm fine if you maintain your repository inside Debian HPC and ping me personally since I do not closely follow this list. Kind regards Andreas. -- https://fam-tille.de
Bug#1086140: ostree: FTBFS against gpg 2.2.45: gpg --import for revocation cert exits 2
On 2024-10-27 Simon McVittie wrote:
[...]
> I can reproduce this. The actual error appears to be:
> > + gpg --homedir=/var/tmp/tap-test.4h3gy2/gpghome --import
> > /var/tmp/tap-test.4h3gy2/gpghome/revocations/key1.rev
> > Imported 0 GPG keys to remote "R1"
> > gpg: key 7FCA23D8472CDAFA: "Ostree Tester " revocation
> > certificate imported
> > gpg: Total number processed: 1
> > gpg:new key revocations: 1
> > gpg: Note: ultimately trusted key 7FCA23D8472CDAFA expired
> > gpg: marginals needed: 3 completes needed: 1 trust model: pgp
> > gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
> > ++ report_err
> > ++ local exit_status=2
> > Unexpected nonzero exit status 2 while running: ${GPG}
> > --homedir=${TEST_GPG_KEYHOME} --import
> > ${TEST_GPG_KEYHOME}/revocations/key1.rev
> Is it intentional that importing a revocation certificate, apparently
> successfully (or at least there are no obvious error/warning messages),
> is now exiting with status 2?
> The failing test script is:
> https://sources.debian.org/src/ostree/2024.8-1/tests/test-remote-gpg-list-keys.sh/
> and the test keys and revoation certificate can be found in:
> https://sources.debian.org/src/ostree/2024.8-1/tests/gpghome/
Hello,
The minimal test case seems to be to expire a key and then import its
revocation certificate. .45 exits with 2 instead of success.
#!/bin/sh
MYGPGHOME=`mktemp -d`
cp -a /tmp/ostree-2024.8/tests/gpghome/* ${MYGPGHOME}/
gpg --homedir=${MYGPGHOME} --version
gpg --homedir=${MYGPGHOME} -K > /dev/null
gpg --verbose --homedir=${MYGPGHOME} \
--quick-set-expire 5E65DE75AB1C501862D476347FCA23D8472CDAFA seconds=1
echo DEBUG quick-expire exit status $?
sleep 2
gpg --verbose --homedir=${MYGPGHOME} --import \
/tmp/ostree-2024.8/tests/gpghome/revocations/key1.rev
echo DEBUG import rev exit status $?
rm -rf ${MYGPGHOME}
Given that gpg 2.4 does not behave this way I think this is probably not
intended.
cu Andeas
--
`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#1086140: ostree: FTBFS against gpg 2.2.45 (testsuite error)
Source: ostree Version: 2024.8-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: gnu...@packages.debian.org Hello, ostree throws a CI error and FTBFS against current sid with gpg 2.2.45: ERROR: tests/test-remote-gpg-list-keys.sh - too few tests run (expected 7, got 6) ERROR: tests/test-remote-gpg-list-keys.sh - exited with status 2 cu Andreas
Bug#1086050: ITS: pcaputils
Source: pcaputils Version: 0.8-1.2 Severity: important X-Debbugs-Cc: Robert S. Edmonds , 691...@bugs.debian.org, 698...@bugs.debian.org, Package Salvaging Team Hi I'm interested in salvaging your package pcaputils, in accordance with the Package Salvaging procedure outlined in the Developers Reference[1]. I realised that you are upstream and Debian Maintainer in one person which makes an ITS a bit unusual - feel free to refuse and simply take over the packaging enhancements we provided (see below). Despite this special situation 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/savage-team/pcaputils [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.11-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#1085946: closed by Debian FTP Masters (reply to Marc Leeman ) (Bug#1085946: fixed in ogmtools 1:1.5-5)
Am Fri, Oct 25, 2024 at 05:07:58PM +0200 schrieb Marc Leeman: > don't remove it just yet: I'll have a look and might move it there > instead of my repo. OK, fine - whatever you prefer. Just make sure you do another upload with updated Vcs fields. Let my know if you need some help. Thank you for your work on this package Andreas. -- https://fam-tille.de
Bug#1085946: closed by Debian FTP Masters (reply to Marc Leeman ) (Bug#1085946: fixed in ogmtools 1:1.5-5)
Hi Marc, > #1085946: ITS: ogmtools > > It has been closed by Debian FTP Masters > (reply to Marc Leeman ). > > Changes: > ogmtools (1:1.5-5) unstable; urgency=medium > . >* Initial upstream branch. >* d/watch: add >* d/control: add Vcs tags (Closes: #1085946) Cool, thanks a lot for catching up. I think it makes sense if I remove the unused reporitory in Multimedia team[1] to avoid any confusion. Just let me know if you have merged anything you intend to keep before I do so. Thanks a lot for keeping on with ogmtools maintenance which is the prefered solution in any case. Kind regards Andreas. [1] https://salsa.debian.org/multimedia-team/ogmtools -- https://fam-tille.de
Bug#1085946: ITS: ogmtools
Hi Marc, Am Thu, Oct 24, 2024 at 01:03:00PM +0200 schrieb Marc Leeman: > > Am Wed, Oct 23, 2024 at 10:40:41PM +0200 schrieb Marc Leeman: > > > I will have a look tomorrow: could be I have converted the repo to > > > pristine-tar some time ago. > > > > The repository I've created in Multimedia team is pristine-tar. > > I guess this is a typical mid-air collision: this morning I dug in my > personal repositories and I had indeed prepared ogmtools. Nice. :-) > I have had a > quick glance at it, fixed a number of packaging issues (the last real > review was years ago, still using cdbs as a build dependency) and > uploaded a new package that fixes a number of low hanging fruit > issues. Yes, this is what we did as well. Cdbs is replaced by dh > There is one that I need to have a look at (dpkg-buildpackage, > dpkg-buildpackage -S; I'll review that one once I have finished my > rust to bookworm backports for something unrelated. > > > The advantage of joining a packaging team is that its easier to find > > sponsors. So I'd recommend to stick to the maintenance inside Debian > > Multimedia team. I've sent you an invitation for the team so you can > > directly access the repository. > > Yeah, I got that since I package GStreamer. I don't really mind where > the repository is housed, so multimedia time is fine by me too. I did > not have a look at that one yet and how it differs from the one I was > using. Simply use what seems to be helpful to you. These bugs are fixed: 375564 732175 905661 The repository is clean in terms of latest packaging standards. > > There was no new upstream release since 20 years. Do you have some > > information that something new is pending? > > No, but that was probably part of (my) problem: to use the upstream > release as a trigger for package uploads. Ahhh. Just let me know if you need further help. Kind regards Andreas. -- https://fam-tille.de
Bug#1024672: How to proceed with slim? (Was: slim: New upstream)
Hi, slim came up as Bug of the Day[1] candidate recently. Since that package seemed of some importance I've answered the bug report about new upstream version[3]. This triggered the following interesting response: Am Thu, Oct 24, 2024 at 11:57:57PM -0500 schrieb Plasma (David Paul): > On Thu, 24 Oct 2024 13:53:56 +0200 > Andreas Tille wrote: > > > Hi Maintainers of slim, > > [...] > > > Regarding the Debian maintenance I would propose moving the project to > > Salsa to anable some fruitful cooperation. IMHO the most natural > > location would be https://salsa.debian.org/debian/slim. However, > > since I'm not sure whether this is also your prefered choice I simply > > created a temporary repostory just for your convenience in the > > Package Salvage team space[2]. I do not intend to keep it there if > > you want to continue maintaining slim but moving the repository to > > some other place is simply easier than if it would be in debian/. > > Because I noticed I didn't include this information when I originally > submitted this bugreport two years, I'd like to draw attention to the > slim package in Devuan which has been tracking Rob Pearce's fork for > the last two years. The packaging git repository for the package in > Devuan can be found at https://git.devuan.org/devuan/slim and can be > used as a starting point for updated packaging for slim in Debian. I've checked Gentoo and Fedora and found these are using the said fork as well. I tried to import single commits of the Devuan Git into the repository I've created[2] for the purpose of salvaging this package. I admit I do not really want to put this package on my own stack of packages but rather like to povide some starting point. This mail is rather a 1. Ping to the Maintainers / Uploaders of this package (I just removed one Uploader where my first mail was bouncing) 2. Call for volunteers who might either help the Maintainers or salvage the package in case they will not show any interest any more 3. Call for a decision what code base we want to maintain 4. Question whether we need slim at all (which was once answered negatively[4]). We have 327 real votes from popcon[5] which is more than typical removal candidates so some users would suffer. No idea whether this might increase with the slim-fork. If we do nothing I expect continued decrease of active usage. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/slim/ [3] https://bugs.debian.org/1024672#10 [4] https://bugs.debian.org/538921 [5] https://qa.debian.org/popcon-graph.php?packages=slim&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 -- https://fam-tille.de
Bug#1086019: RM: pentium-builder -- RoQA; Seems to be outdated, has nearly no users
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pentium-buil...@packages.debian.org, Alex Pennace , Package Salvaging Team Control: affects -1 + src:pentium-builder User: ftp.debian@packages.debian.org Usertags: remove Hi, the package pentium-builder came up as candidate for the Bug of the Day[1]. I've checked the package which contains two tiny Perl scripts setting environment variables. The according manpages contain information like DEBIAN_BUILDARCH If set, the architecture to compile for. Useful values are pentium or pentiumpro. DEBIAN_BUILDGCCVER If set, the version of gcc to be invoked. Useful values are 3.0 or 2.95. which seems to solve problems way in the past. I see a lot of open bugs[2] for this package - most of them with no answer from the maintainer. I'd suggest to remove this package from Debian. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pentium-builder
Bug#1080956: SaunaFS
Hi Urmas, Am Thu, Oct 24, 2024 at 06:57:04AM + schrieb Urmas Rist: > Hello Tony! > > > https://github.com/leil-io/debian-package > > Sorry for the confusion, but that URL is going to be mostly used by ourselves > for building our own binaries targeting Ubuntu 22.04 and 24.04, it's not meant > for Debian despite the confusing name (I went with the technical term since > it's possible to use this on any system with the Debian package manager, > provide you probably do some patching). The package was taken from the source > repository to re-organize our building process in preparation for a new > delivery pipeline I'm developing. > > I have however worked in my spare time on a package specifically for Debian, > especially during the previous week (in fact, the re-organization above was > inspired by this). I heavily used the previous LizardFS package to work on > this, which aligns with Debian rules much better than the above URL. > > I've managed to get it to compile on sid, but there's still some lintian > issues > to work on and one binary (saunafs-uraft) is still missing. I haven't uploaded > this package anywhere since it's completely ready yet, however I might upload > it for (early) review and testing if there's interest. The best idea to get help and reviews is to maintain the Debian packaging on https://salsa.debian.org. Its not really a bioinformatics packages but there is a Debian HPC team where it might be a good fit. Please let me know if you agree and I'll happily smoothen your way into this team. > My main question is where to upload it? Would mentors.debian.net be fine even > if unfinished or is there somewhere better? I might just temporarily upload to > Github until a better place is found. For several reasons Github is not the best place. There is mentors.debian.net but my personal sponsoring policy is that I sponsor from Salsa only since it enables me to do simple polising easily which is quite straightforward for the sponsee. > Also, maybe #1080956 > (https://lists.debian.org/debian-devel/2024/09/msg00115.html) would be a > better > thread for this? ITP #1080956 in CC. Kind regards Andreas. -- https://fam-tille.de
Bug#1084853: broadcom-sta-dkms: Warnings on linux-6.11: "Unpatched return thunk...", 'memcpy: detected field-spanning write... "dst"...'
On Wed, 09 Oct 2024 17:04:33 -0500 Diego Escalante Urrelo wrote: Package: broadcom-sta-dkms Version: 6.30.223.271-24 On 6.11, it seems there are a few API updates we need to take care of: Something called a "return thunk": This reminds me of https://bugs.debian.org/1052069 in the proprietary legacy nvidia driver. > I have not tried this out long enough to see if it has real > consequences, but as usual it would be great to fix these. But fwiw, it > seems these are harmless _for now_. I'd guess that they are harmless only on (older) CPUs not supporting IBT (indirect branch tracking). This needs an upstream fix, the blobs need to be recompiled with different options to generate these return thunks. As a workaround you could boot with ibt=off. For the legacy nvidia drivers I added a check (to the non-blob parts of the module source) to make the module fail to load with a (hopefully) informative error message if it is being loaded while IBT is enabled: https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers/-/blob/470/debian/module/debian/patches/0033-refuse-to-load-legacy-module-if-IBT-is-enabled.patch?ref_type=heads Andreas
Bug#1086004: ITS: perforate
Source: perforate Version: 1.2-5.3 Severity: important X-Debbugs-Cc: 406...@bugs.debian.org, 564...@bugs.debian.org, 940...@bugs.debian.org, Amaya Rodrigo Sastre , Hector Garcia , Package Salvaging Team Hi I'm interested in salvaging your package perforate, 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/perforate [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.11-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#539340: Is debfoster actively maintained?
Hi Maintainers of debfoster, your package showed up as a candidate for the Bug of the Day[1] today and thus I had a look. The last maintainer upload was 10 years ago and there are a lot of bugs that are not answered by a maintainer. For proper maintenance of this native package I would propose moving the project to Salsa to enable some fruitful cooperation. IMHO the most natural location would be https://salsa.debian.org/debian/debfoster. However, since I'm not sure whether this is also your prefered choice (seems some debfoster team existed and you want to create your own team space) I simply created a temporary repostory just for your convenience in the Package Salvage team space[2]. I do not intend to keep it there if you want to continue maintaining debfoster but moving the repository to some other place is simply easier than if it would be in debian/. I would be delighted if you would give us some status update whether you intend to keep on with the development and maintenance (which would be really prefered). If you will not answer this mail in 21 days (the usual Intend to Salvage period) we might bring up this discussion again and decide inside the Package Salvage team what might be the best course of action. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/debfoster/ -- https://fam-tille.de -- https://fam-tille.de
Bug#1013230: qqwing uploaded to delayed=10 as per ITS bug
Control: tags -1 pending Thanks Hi Jackson, as per ITS bug I have uploaded qqwing to delayed=10. Kind regards Andreas. -- https://fam-tille.de
Bug#1024672: slim: New upstream
Hi Maintainers of slim, your package showed up as a candidate for the Bug of the Day[1] today and thus I had a look. I consider this specific bug pointing to some upstream for realy interesting. While I personally do not understand the explanation: Then the code got moved to Github. Then all the maintainers lost interest and it died. ... So I've forked it which tries to explain that the project was forked instead of simply taking over the maintenance on Github which I would consider the most natural thing to do in such cases. However, given tat several Gentoo issues are fixed (which might be identical or similar to Debian bugs which I did not checked) I consider switching to some living project a sensible step forward. Regarding the Debian maintenance I would propose moving the project to Salsa to anable some fruitful cooperation. IMHO the most natural location would be https://salsa.debian.org/debian/slim. However, since I'm not sure whether this is also your prefered choice I simply created a temporary repostory just for your convenience in the Package Salvage team space[2]. I do not intend to keep it there if you want to continue maintaining slim but moving the repository to some other place is simply easier than if it would be in debian/. I would be delighted if you would let us know what you think about the fork and whether you intend to keep on with the maintenance (which would be really prefered). If you will not answer this mail in 21 days (the usual Intend to Salvage period) we might bring up this discussion again and decide inside the Package Salvage team what might be the best course of action. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/slim/ -- https://fam-tille.de
Bug#1085946: ITS: ogmtools
Hi Marc, Am Wed, Oct 23, 2024 at 10:40:41PM +0200 schrieb Marc Leeman: > I will have a look tomorrow: could be I have converted the repo to > pristine-tar some time ago. The repository I've created in Multimedia team is pristine-tar. > On Wed, 23 Oct 2024, 22:15 Marc Leeman, wrote: > > > I do not plan give up maintenance of this package: That's good to know. > > The main problem used to be that I did not have upload rights and had to > > scavenge for sponsors, but this is not the case for over a year [1]. The advantage of joining a packaging team is that its easier to find sponsors. So I'd recommend to stick to the maintenance inside Debian Multimedia team. I've sent you an invitation for the team so you can directly access the repository. > > Most bugs are old and probably outdated, will be fixed with a new upstream > > release. There was no new upstream release since 20 years. Do you have some information that something new is pending? Kind regards and thanks a lot for your quick response Andreas. > > [1] https://qa.debian.org/developer.php?login=m.leeman%40televic.com > > > > On Wed, 23 Oct 2024, 21:30 Andreas Tille, wrote: > > > >> Source: ogmtools > >> Version: 1:1.5-4.1 > >> Severity: important > >> X-Debbugs-Cc: 375...@bugs.debian.org, 732...@bugs.debian.org, > >> 905...@bugs.debian.org, Debian Multimedia Maintainers < > >> debian-multime...@lists.debian.org>, Marc Leeman , > >> Package Salvaging Team > >> > >> Hi > >> > >> I'm interested in salvaging your package ogmtools, 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 believe your package would be a great addition to the Debian > >> Multimedia team, and I'm planning to create 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/ogmtools > >> [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.11-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 > >> > > -- https://fam-tille.de
Bug#1085968: nvidia-graphics-drivers: CVE-2024-0126
Source: nvidia-graphics-drivers Severity: serious Tags: security upstream X-Debbugs-Cc: Debian Security Team Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 Control: reassign -2 src:nvidia-graphics-drivers-legacy-340xx 340.76-6 Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2024-0126 Control: tag -2 + wontfix Control: reassign -3 src:nvidia-graphics-drivers-legacy-390xx 390.48-4 Control: retitle -3 nvidia-graphics-drivers-legacy-390xx: CVE-2024-0126 Control: tag -3 + wontfix Control: reassign -4 src:nvidia-graphics-drivers-tesla-418 418.87.01-1 Control: retitle -4 nvidia-graphics-drivers-tesla-418: CVE-2024-0126 Control: tag -4 + wontfix Control: reassign -5 src:nvidia-graphics-drivers-tesla-450 450.51.05-1 Control: retitle -5 nvidia-graphics-drivers-tesla-450: CVE-2024-0126 Control: tag -5 + wontfix Control: close -5 450.248.02-4 Control: reassign -6 src:nvidia-graphics-drivers-tesla-460 460.32.03-1 Control: retitle -6 nvidia-graphics-drivers-tesla-460: CVE-2024-0126 Control: tag -6 + wontfix Control: close -6 460.106.00-3 Control: reassign -7 src:nvidia-graphics-drivers-tesla-470 470.57.02-1 Control: retitle -7 nvidia-graphics-drivers-tesla-470: CVE-2024-0126 Control: tag -7 + wontfix Control: severity -7 + important Control: reassign -8 src:nvidia-graphics-drivers-tesla 510.85.02-1 Control: retitle -8 nvidia-graphics-drivers-tesla: CVE-2024-0126 Control: found -8 515.48.07-1 Control: found -8 525.60.13-1 Control: tag -8 + wontfix Control: close -8 525.147.05-6 Control: reassign -9 src:nvidia-open-gpu-kernel-modules 515.43.04-1 Control: retitle -9 nvidia-open-gpu-kernel-modules: CVE-2024-0126 Control: found -9 520.56.06-1 Control: found -9 525.85.12-1 Control: found -9 530.30.02-1 Control: found -9 535.43.02-1 Control: found -9 545.23.06-1 Control: found -9 550.40.07-1 Control: found -9 555.42.02-1 Control: found -9 560.28.03-1 Control: found -9 565.57.01-1 Control: found -1 340.24-1 Control: found -1 343.22-1 Control: found -1 396.18-1 Control: found -1 430.14-1 Control: found -1 455.23.04-1 Control: found -1 465.24.02-1 Control: found -1 495.44-1 Control: found -1 515.48.07-1 Control: found -1 520.56.06-1 Control: found -1 525.53-1 Control: found -1 530.30.02-1 Control: found -1 535.43.02-1 Control: found -1 545.23.06-1 Control: found -1 550.40.07-1 Control: found -1 555.42.02-1 Control: found -1 560.28.03-1 Control: found -1 565.57.01-1 https://nvidia.custhelp.com/app/answers/detail/a_id/5586 CVE-2024-0126 NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability which could allow a privileged attacker to escalate permissions. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. Linux Driver Branch CVEs Addressed R565, R550, R535CVE-2024-0126 Driver Branch Affected Driver VersionsUpdated Driver Version R565All driver versions prior to 565.57.01 565.57.01 R550All driver versions prior to 550.127.05 550.127.05 R535All driver versions prior to 535.216.01 535.216.01 Andreas
Bug#1080317: NMU for s390-tools
On Wed, 23 Oct 2024 20:53:14 +0200 Michael Biebl wrote: I've made an NMU to DELAYED/3 fixing the two open RC bugs. s390-tools is orphaned (#1084987), so you should rather do a QA upload (and update the maintainer to QA) instead of a NMU. Andreas
Bug#1085946: ITS: ogmtools
Source: ogmtools Version: 1:1.5-4.1 Severity: important X-Debbugs-Cc: 375...@bugs.debian.org, 732...@bugs.debian.org, 905...@bugs.debian.org, Debian Multimedia Maintainers , Marc Leeman , Package Salvaging Team Hi I'm interested in salvaging your package ogmtools, 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 believe your package would be a great addition to the Debian Multimedia team, and I'm planning to create 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/ogmtools [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.11-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#1084299: mintpy: FTBFS: Resource wordnet not found.
Am Wed, Oct 23, 2024 at 12:08:47PM +0200 schrieb Santiago Vila:
> So everything should be fine now.
Puhhh, thanks a lot
Andreas.
--
https://fam-tille.de
Bug#1084299: mintpy: FTBFS: Resource wordnet not found.
Control: reassign -1 python3-nltk
Thanks
Am Mon, Oct 07, 2024 at 10:33:52AM +0200 schrieb Santiago Vila:
> ...
> Successfully built mintpy-1.6.1-py3-none-any.whl
> I: pybuild plugin_pyproject:144: Unpacking wheel built for python3.12 with
> "installer" module
> mkdocs build -c -f mkdocs.yml --no-directory-urls -d .pybuild/docs/html
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/nltk/corpus/util.py", line 84, in
> __load
> root = nltk.data.find(f"{self.subdir}/{zip_name}")
>^^^
> File "/usr/lib/python3/dist-packages/nltk/data.py", line 579, in find
^^^
Seems the problem is caused by python3-nltk. This seems to depend
from
https://github.com/goodmami/wn
As the Uploader of the Debian package wordnet that should not be really
hard but currently I do not want to touch new packages. Please let me
know if you urgently need assistance.
> raise LookupError(resource_not_found)
> LookupError:
> **
> Resource [93mwordnet[0m not found.
> Please use the NLTK Downloader to obtain the resource:
>
> [31m>>> import nltk
> >>> nltk.download('wordnet')
> [0m
Kind regards
Andreas.
--
https://fam-tille.de
Bug#1085351: camo: Permission for team upload of camo
Hi Luke, Am Tue, Oct 22, 2024 at 06:38:12PM -0700 schrieb Luke Faraone: > Thank you for your efforts. The ZDPT isn't currently active, as maintaining > Zulip dependencies in Debian proper hasn't been staffed since Zulip was > acquired by Dropbox in 2014. Thank you for the explanation. > Publishing a repo on Salsa as you propose is fine with me. I've just sponsored the package on behalf of наб who fixed the final bits. Kind regards Andreas. > On Fri, 18 Oct 2024, 07:39 Andreas Tille, wrote: > > > Source: camo > > Version: 2.3.0+dfsg-1.1 > > Severity: important > > X-Debbugs-Cc: Zulip Debian Packaging Team , Luke > > Faraone , 845...@bugs.debian.org, Package Salvaging > > Team , 732...@bugs.debian.org > > > > Hi Luke, > > > > Your package camo was highlighted in the Bug of the Day[1] 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. > > > > Usually we file Intend To Salvage bugs[2] if we move some package from > > invalid VCS (=old Alioth) to Salsa. However, I have seen the maintainer > > is just a team (Zulip Debian Packaging Team) and it seems well located > > inside this team. Thus salvaging is not the correct procedure since we > > do not intend to change the team - just make it available on Salsa to > > enable better cooperation between developers. I'm just filing this > > ITS-like bug report to formalise and document the procedure. > > > > Since there is no team space on Salsa for the Zulip Debian Packaging > > Team (yet) I have migrated the packaging to debian team[3] (which > > perfectly fits its former location under collab-maint). I've fixed > > the two bugs that are in CC and modernised the packaging. The package > > salvage team is also busy adding systemd support which would fix the > > last open bug. I just want to ask you kindly to permit a team upload > > to make those fixes and the new Vcs location public. > > > > 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 > > [3] https://salsa.debian.org/debian/camo > > > > > > -- 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.11-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 > > -- https://fam-tille.de
Bug#1085870: RM: jqapi -- RoQA; Outdated documentation not maintained in Debian, users might read online
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: jq...@packages.debian.org, 734...@bugs.debian.org, Package Salvaging Team , Debian Javascript Maintainers , Marcelo Jorge Vieira Control: affects -1 + src:jqapi User: ftp.debian@packages.debian.org Usertags: remove Hi, there is a 10 year old bug (#734598) requesting packaging a new version of the jQuery documentation. The package was only uploaded once by the maintainer and there was one NMU. IMHO outdated packaged doc is worse than telling people to read the always up to date online documentation. So lets remove this package. Kind regards Andreas.
Bug#1083052: RFS: vimium/2.1.2-1 [ITP] -- keyboard-based navigation and control
Hi Soren, On Monday, 21st October 2024 at 16:06:58 -07:00:00 Soren Stoutner wrote: I think the following MR should fix the issue: https://salsa.debian.org/andreas82/vimium/-/merge_requests/1 thanks for the changes. I get it now. Everything has been merged. Just for info. You already explained that the source-is-missing tag is an experimental tag and isn't considered necessary to override. Package builds by the use of pbuilder without any lintian warnings on current Debian Sid. On current Debian Stable as well as on mentors.debian.net I get a lintian error for source-is-missing [content_scripts/mode_visual.js] Regards, Andreas
Bug#1085703: ITS: python-iowait by Debian Python team
Hi, as suggested I moved the package to DPT at https://salsa.debian.org/python-team/packages/python-iowait Kind regards Andreas -- https://fam-tille.de
Bug#898699: [Pending] Version 0.2 available, fixes important bug
Control: tags -1 pending Thanks Hi, lua-mmdb came up as candidate for the Bug of the Day[1]. I've fixed the open bug (requesting a new upstream version) and modernised the packaging and created a MR[2] since I'm not a member of the Lua team (yet). Please either accept me as member of the team so I can do a team upload or merge and do a team upload yourself. Hope this helps Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/lua-team/lua-mmdb/-/merge_requests/2 -- https://fam-tille.de
Bug#1085409: cdrkit: Moving cdrkit to Salsa (not really ITS)
Hi Steve, Am Tue, Oct 22, 2024 at 11:14:17AM +0100 schrieb Steve McIntyre: > On Tue, Oct 22, 2024 at 11:14:15AM +0200, Andreas Tille wrote: > >could you answer the question whether there is some VCS repository > >somewhere available that could be turned into some Git repository on > >Salsa simply to keep the development history? It would be a shame if we > >would simply need to rely on `gbp import-dscs ` to create some > >repository. > > I have an old svn checkout that dates back to 2009, in the space > before the 9:1.1.10-1 upload. I'm not sure how useful that might be. Given that this is just one micro-release before the latest "upstream" release this sounds like "better than nothing". Not sure whether `gbp import-dscs` can somehow "continue" from this point. Honestly, you will probably know better than me whether this is a good starting point. If we do not have anything better I'd volunteer to convert this to Git and push it to salsa:debian/cdrkit which seems to be the best place, IMHO. Kind regards Andreas. -- https://fam-tille.de
Bug#1085409: cdrkit: Moving cdrkit to Salsa (not really ITS)
Hi again, could you answer the question whether there is some VCS repository somewhere available that could be turned into some Git repository on Salsa simply to keep the development history? It would be a shame if we would simply need to rely on `gbp import-dscs ` to create some repository. Kind regards Andreas. Am Mon, Oct 21, 2024 at 11:05:15AM +0200 schrieb Andreas Tille: > Hi Sune, > > Am Mon, Oct 21, 2024 at 08:37:15AM +0200 schrieb Sune Stolborg Vuorela: > > On Saturday, October 19, 2024 5:25:50 PM CEST Andreas Tille wrote: > > > To do > > > so the maintainer confirmation is needed. > > > > Just for completeness, we (me, joerg, steve) intentionally let cdrkit.org > > expire, who were the debian people as well as upstream. > > Thank you for thi extra information. > > > I don't think there is much maintaining going on nowadays. > > What do you think about my intention to maintain the package under > the debian/ team on Salsa (which basically was my question)? > > Kind regards >Andreas. > > -- > https://fam-tille.de -- https://fam-tille.de
