Bug#1061212: Please upgrade to llvm-toolchain-17

2024-03-16 Thread Bastian Germann

v3.1.44 should be the best upstream version for this.



Bug#974972: unar: There is a new upstream version

2024-04-14 Thread Bastian Germann

Please use the new package universal-detector for importing the new version.



Bug#1061212: Please upgrade to llvm-toolchain-18

2024-07-07 Thread Bastian Germann
That version was the last to build on llvm-toolchain-17. Now that 
llvm-toolchain-18 is asked for, it should be a different one.
I have update the git master to 3.1.61 but that fails to build currently and 
would appreciate someone to make the package build.



Bug#1081135: RM: autoconf2.13 -- RoQA; severely outdated package

2024-09-08 Thread Bastian Germann

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: autoconf2...@packages.debian.org
Control: affects -1 + src:autoconf2.13
Control: block -1 by 343083
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove autoconf2.13 as soon as xemacs21 has moved on to a newer autoconf 
version.



Bug#1081532: autoconf2.13: Keep out of trixie

2024-09-12 Thread Bastian Germann
Source: autoconf2.13
Severity: serious
Version: 2.13-69

With the last reverse dependency xemacs21 not being in trixie, this package can 
leave as well.
If xemacs21 can otherwise enter trixie again and has not migrated to a newer 
autoconf,
please just close this bug to let it migrate.



Bug#1014120: libowfat FTBFS: ln: failed to create hard link 'libowfat/buffer.h'

2022-09-14 Thread Bastian Germann

I have tried to fix this but as I am not able to reproduce this locally I am at 
a loss here.
Maybe someone else has an idea...



Bug#1014120: libowfat FTBFS: ln: failed to create hard link 'libowfat/buffer.h'

2022-09-15 Thread Bastian Germann

Am 15.09.22 um 03:35 schrieb Bo YU:

It was the new issue:


When that is fixed, the buildds are going to bump into this one again.
No need to reference unrelated issues.



Bug#1020933: cadabra: Drop Build-Depends: libpcre++-dev

2022-09-28 Thread Bastian Germann

Source: cadabra
Version: 1.46-5
Severity: minor
Control: block 1017984 by -1

Please drop the optional build dependency libpcre++-dev to contribute to the 
effort of getting rid of libpcre3: #159



Bug#1021094: dnprogs: obsolete? time to remove?

2022-11-23 Thread Bastian Germann

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: dnprogs -- RoQA; obsolete; orphaned; bad packaging

DECnet was dropped from 6.1 rc, so this package should be gone.



Bug#673406: Shouldn't be a native Debian package

2022-11-28 Thread Bastian Germann

Control: severity -1 serious

Please fix this if you want to keep the package in Debian.



Bug#993301: prototypejs: FTBFS

2022-12-03 Thread Bastian Germann

X-Debbugs-Cc: y...@debian.org

On Fri, 19 Nov 2021 08:32:52 +0100 Andreas Beckmann wrote:

> Sée thé salsa tree un order to understand why i need rake

Which repository are you talking about?


I guess https://salsa.debian.org/js-team/prototypejs, which is a repo 
introduced by the JS Team to adopt this package.
However, it has diverged from the archive and was not updated since the last 
upload.



Bug#562702: python-pam: Debian differences not clearly separated from upstream source

2022-12-03 Thread Bastian Germann

Control: severity -1 serious
X-Debbugs-Cc: d...@debian.org

On Sun, 27 Dec 2009 17:28:04 +1100 Ben Finney  
wrote:

However, the ‘python-pam_0.4.2.orig.tar.gz’ does not match the actual
file at http://www.pangalactic.org/PyPAM/PyPAM-0.4.2.tar.gz>,
with many significant changes.

These changes should be separated from the pristine upstream source
(in a ‘python-pam_0.4.2-nn.diff.gz’, if using the Debian source format
1.0) and the ‘python-pam_0.4.2.orig.tar.gz’ should match the tarball
available from upstream.

The provenance of these changes should also be recorded in the Debian
copyright file for the package.


The upstream source is no longer available. There is a fork including py3 
support available at
https://github.com/openEuler-BaseService/PyPAM.

We should switch to that as upstream or drop this package entirely.
I am copying Matthias as he worked on the package mostly since it was abandoned.
For now, make this serious, to keep this out of bookworm in favour of 
pam-python.



Bug#1028066: sleekxmpp: contains non-free fonts

2023-01-06 Thread Bastian Germann

Source: sleekxmpp
Version: 1.3.3-9
Severity: serious

sleekxmpp contains two versions of the non-free Museo Slab font: 
https://www.exljbris.com/museoslab.html
Please replace to get rid of them.



Bug#562702: python-pam: Debian differences not clearly separated from upstream source

2023-01-25 Thread Bastian Germann

Control: severity -1 normal

On Wed, 25 Jan 2023 22:24:39 +0100 Sebastian Ramacher  
wrote:

This seems like it would be easy enough to fix.


Yes but it also shows that pam-python is not really a replacement for 
python-pam.
So I am resetting the severity.



Bug#1031278: buddy: Contains non-source file

2023-02-14 Thread Bastian Germann

Source: buddy
Version: 2.4-11
Severity: serious

The doc/buddy.ps file contained in the package is not a source file.
Please repack to get rid of it or build it from source if it is available.



Bug#1031512: docbook-defguide: non-free GFDL-licensed files

2023-02-17 Thread Bastian Germann

Source: docbook-defguide
Severity: serious
Version: 2.0.17+svn9912-2

Some files in the package are licensed under the non-free variant of the GFDL 
with explicit Invariant Section.
Please repack to remove them.



Bug#1026431: Remove scalc for bookworm?

2023-02-23 Thread Bastian Germann

Control: retitle -1 RM: scalc -- RoQA; orphaned; no reverse deps
Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove scalc from the archive. There is no real use of it and popcon is 
very low.



Bug#998889: libcommoncpp2: Remove in bookworm?

2023-02-23 Thread Bastian Germann

Control: severity -1 normal
Control: retitle -1 RM: libcommoncpp2 -- RoQA; orphaned; RC-buggy; better 
alternative available
Control: reassign -1 ftp.debian.org

Yes, the package should be gone from unstable as well.



Bug#962065: rdist: Non-free license

2023-02-23 Thread Bastian Germann

The 7.0 alpha version has been relicensed but this license still occurs in at 
least one file (missing/strcasecmp.c).



Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

2023-03-15 Thread Bastian Germann

Am 15.03.23 um 22:39 schrieb Paul Gevers:

Hi,

[Release Team here]

On Thu, 2 Mar 2023 18:42:56 +0100 Bastian Germann  wrote:

On Thu, 2 Mar 2023 05:10:41 +0100 Guilhem Moulin  wrote:
> Ah no my bad, the changelog entry is probably incorrect and the
> cryptsetup-initramfs breakage is caused by the recent libargon2 upload
> indeed, but AFAICT not by anything particular in the upload.

I am sorry for having caused that issue, Daniel. Thanks for investigating, 
Guilhem.

The changelog entry is correct because it fixes a formerly made change.
0~20171227-0.1 intended to compile only udeb without threads:
"Build udeb without a dependency on pthreads"
But it unintentionally compiled the .deb executable with the .a compiled 
without threads.
The additional "make clean" fixes accidentally picking up the wrong .a.


Do I understand correctly that:
1) argon2 in testing isn't affected
2) this bug isn't solved yet, despite the closure?
3) the issue for cryptsetup is worked around in cryptsetup

libargon2-1 is linked by more packages. Are they all OK without this unintentional change unfixed? Why is the 
unintentional change not reverted or fixed?


There is no unintentional change. If packages are waiting for argon2 then I would prefer an unblock of both argon2 and 
cryptsetup at the same time. The version change seems major but the diff shows mostly build files changed.


I scheduled the build in time for the hard freeze but as the excuses system did not catch the bug severity/fixed changes 
it was not considered for migration.




Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

2023-03-16 Thread Bastian Germann

Am 16.03.23 um 09:13 schrieb Paul Gevers:
I'm not 100% sure I parse that sentence as you intended, so let me ask explicitly: if we binNMU (now or in the future) 
src:argon2 version 0~20171227-0.3 in bookworm, would it also loose its linking to libpthread? That would be a time bomb 
(not only in the archive, but also for downstreams and other users that do rebuilds). I *think* you're saying that 
despite libc's version, that is *not* the case.


Time bomb confirmed.

For the record, with my current understanding I prefer the scenario of keeping the versions of argon2 and cryptsetup in 
bookworm as they are. Feel free to convince the Release Team of the opposite in an unblock request.


cryptsetup will need to migrate to mitigate the time bomb.

As I already mentioned on this or some related bug, I would find it nice for #1014110 to be fixed in bookworm (threaded 
argon2 executable) but I do not insist on it.




Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

2023-03-23 Thread Bastian Germann

Am 23.03.23 um 09:58 schrieb Paul Gevers:
Bastian, if you really want that threaded bug fixed, please prepare a targeted fix based on the version currently in 
bookworm and revert all other changes. We can then review the targeted fix. But I'll not unblock the version of argon2 
as it's currently is in unstable.


I am not going to do that. It is okay for me as-is. Originally, I wanted to upload a targeted fix but then I saw that 
the new version was already imported in git, so I went with that.




Bug#1032234: cryptsetup-initramfs: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

2023-04-04 Thread Bastian Germann

Hi Ondřej,

Please use the original bug. I have changed the BTS address.

Am 04.04.23 um 22:25 schrieb Ondřej Surý:

I went through the upstream changes between 20171227..20190702
and as far as I can tell, there's nothing important in there:

...
Out of these, there are only two commits that might be of interest:

cfa4385e728116989ad88b4be7c23b4868422778 Wait for already running threads if a 
thread creation failed.
fea3943adadf6527d1e839a2953e9591896e628d Use explicit_bzero() on recent glibc 
versions

But it's not like the world will be on fire if those were not backported to 
2017 version.


I do not think you need any upstream changes to fix #1032234 in the 2017 
version. Just apply this commit to it:
https://salsa.debian.org/debian/argon2/-/commit/c2152a2766fc73dd88a7d9e88bb9887cf31f1b1b

Cheers,
Bastian



Bug#1038864: RM: dhcpcd-dbus -- RoQA; orphaned; not needed anymore; dead upstream

2023-06-22 Thread Bastian Germann

Package: ftp.debian.org
Control: affects -1 + src:dhcpcd-dbus
X-Debbugs-Cc: dhcpcd-d...@packages.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal

Please remove dhcpcd-dbus. dhcpcd-ui used to depend on dhcpcd-dbus. That was 
its purpose in the archive.
It is no longer needed, orphaned, and not available upstream (after a move to 
GitHub for the related projects).



Bug#1043510: RM: rox -- RoQA; dead upstream; depends on gtk2

2023-08-12 Thread Bastian Germann

Source: rox
Severity: serious
Version: 1:2.11-7

rox does not seem to be used a lot anymore. I intend to file a RM bug.
If you have any reasons to keep it in Debian please voice them here.
To get people's attention, I am filing as a serious bug and will reassign to the FTP team when the 
package is autoremoved from testing.




Bug#1049422: transition: dbus-c++

2023-08-15 Thread Bastian Germann

Package: release.debian.org
Control: affects -1 + src:dbus-c++
X-Debbugs-Cc: dbus-...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

libdbus-c++-1-0v5 has been split in the experimental version 0.9.0-13 into
three packages containing each of the shared object files which were previously
all in libdbus-c++-1-0v5. libdbus-c++-1-0v5 did not gain dependencies on the
two other packages, so in my opinion, a transition is needed. The ABIs have
not changed, however.

I have just uploaded experimental version 0.9.0-14, which is the one that the
transition testing should target.



Bug#1000097: compton: depends on obsolete pcre3 library

2023-08-17 Thread Bastian Germann

It can be built without pcre by adding the following to d/rules:

override_dh_auto_build:
dh_auto_build -- NO_REGEX_PCRE=1



Bug#999937: tup: depends on obsolete pcre3 library

2023-08-29 Thread Bastian Germann

On Tue, 31 Jan 2023 21:36:46 +0800 Bo YU  wrote:

The upstream has tried to switch pcre2[0], but the backporting is not easy,
so maybe waiting a new release is good iead.

[0]: 
https://github.com/gittup/tup/commit/f26bc1e8c0b87d9d351e062c7d27afbbdc53869d


I have started a backport in git but there is at least one linker flag missing.



Bug#1051398: collada2gltf: Missing source in d/copyright

2023-09-07 Thread Bastian Germann

Source: collada2gltf
Version: 20140924-9
Severity: serious

The upstream source is missing from d/copyright. This is a Policy violation.
Please add the upstream URL where the tarball was obtained.



Bug#967324: eboard: depends on deprecated GTK 2

2023-09-10 Thread Bastian Germann

Am 10.09.23 um 15:44 schrieb Francesco Poli:

After a quick search, I found

   xboard 

and maybe

   tagua 
   scid 

Any other?


Certainly pychess, which should be the most popular one.


Which ones may be used to play chess with package 'stockfish'?
Possibly through 'polyglot'?


Right. I think pychess can work as UCI client as well.



Bug#1051006: smuxi: useless empty package

2023-09-16 Thread Bastian Germann

Control: severity -1 normal

The package is not migrating even though it is fixed.



Bug#1037374: giggle: build-depends on transitional package libgdk-pixbuf2.0-dev

2023-09-17 Thread Bastian Germann

Version: 0.7-6



Bug#1043510: RM: rox -- RoQA; dead upstream; depends on gtk2

2023-09-19 Thread Bastian Germann

Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove rox. It is orphaned and dead upstream.
It also depends on the deprecated gtk2, which will obviously not be fixed.
Nobody chimed in on the RM announcement to keep it in Debian.



Bug#1019033: Updating the closure-compiler Uploaders list

2023-09-19 Thread Bastian Germann

Version: 20130227+dfsg1-11



Bug#1054301: RM: glfer -- RoQA; orphaned; dead upstream; depends on gtk2

2023-10-21 Thread Bastian Germann

Source: glfer
Severity: serious

glfer is orphaned for 14 years and dead upstream. It also depends on the 
obsolete GTK 2.
I am going to file a RM bug when this is autoremoved from testing and nobody 
objects.



Bug#1054303: RM: gscanbus -- RoQA; orphaned; dead upstream; depends on gtk2

2023-10-21 Thread Bastian Germann

Source: gscanbus
Severity: serious

gscanbus is orphaned for 7 years and dead upstream. It also depends on the 
obsolete GTK 2.
I am going to file a RM bug when this is autoremoved from testing and nobody 
objects.



Bug#1054406: RM: gtick -- RoQA; orphaned; alternative exists; depends on gtk2

2023-10-23 Thread Bastian Germann

Source: gtick

The gtick package should be removed in case gnome-metronome enters Debian in its Rust version, which 
is being prepared at https://salsa.debian.org/a-wai/gnome-metronome/-/merge_requests/1


gtick is orphaned, depends on the obsolete GTK2, and gnome-metronome is a 
better alternative.
Upstream development seems to have stalled.

I am going to file a RM bug as soon as gnome-metronome has entered testing and 
nobody has objected.



Bug#1054406: RM: gtick -- RoQA; orphaned; alternative exists; depends on gtk2

2023-11-02 Thread Bastian Germann

Control: reassign -1 ftp.debian.org

Please remove gtick. It is orphaned and depends on obsolete gtk2.
With gnome-metronome, there is a better alternative available.



Bug#1055722: Missing utility db_tuner? Missing package on debian salsa?

2023-11-10 Thread Bastian Germann

Package: db5.3-util
X-Debbugs-Cc: simonsobi...@gnu.org
Severity: wishlist
Version: 5.3.28+dfsg1-0.5

Am 09.11.23 um 22:27 schrieb Simon Sobisch:
As far as seen from https://github.com/hyc/BerkeleyDB/commits/master/util/db_tuner.c that was a new tool in presumably 
BDB 5.2.28.


I know BDB is late in the phase of "move out", but do you have any idea why the db_tuner binary is not distributed? Is 
it actually built?


For the future: Please file such requests on the Debian bug tracking system. I am doing so for you on the right package. 
The file usr/bin/db5.3_upgrade is just not listed in debian/db5.3-util.install.



How can I build the package on my own?


Note that "apt source db-util" prompted a note about
git://anonscm.debian.org/pkg-db/db-defaults.git
which is also referenced in
https://packages.debian.org/source/buster/db-defaults

-> but anonscm.debian.org is gone... and I can't find it in debian salsa either.


That package is not maintained in git anymore. Buster is an old release and the 
current one does not link to git.
But the actual package that db-util points to is db5.3-util, which you should 
build (from source package db5.3).



Bug#1059654: RM: tablix2 -- RoQA; orphaned; upstream deprecation notice; very low popcon

2024-01-14 Thread Bastian Germann

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: tablix2 -- RoQA; orphaned; upstream deprecation notice; 
very low popcon

Please remove tablix2. It is orphand, has a deprecation notice on its website, 
and has a very low popcon.



Bug#1060855: RM: nxcl -- RoQA; orphaned; dead upstream

2024-01-15 Thread Bastian Germann

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: n...@packages.debian.org, alexandre.deti...@gmail.com
Control: affects -1 + src:nxcl

Please remove nxcl from the archive. It is orphaned since 2014 and dead 
upstream.
It also has a very low popcon, so it is most probably unused.
With nx-libs, there is a maintained alternative.

Am 15.01.24 um 12:14 schrieb Alexandre Detiste:

$ apt rdepends libnxcl1
libnxcl1
Reverse Depends:
   Depends: libnxcl-dev (= 0.9-3.1+b1)
   Depends: libnxcl-bin

https://qa.debian.org/popcon.php?package=nxcl




Bug#1061645: transition: poco

2024-01-27 Thread Bastian Germann

Package: release.debian.org
Control: affects -1 poco
X-Debbugs-Cc: p...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
Control: forwarded -1 https://release.debian.org/transitions/html/auto-poco.html

poco is available in experimental with the libraries' SOVERSIONs at 100.
This transition is from SOVERSION 80.
The auto-generated Ben file is okay and all reverse dependencies build fine.



Bug#953006: Switch to current libreadline

2020-03-02 Thread Bastian Germann
Package: dbacl
Severity: normal

The package is not bound by license to build against the old
libreadline5. It can also use the current GPL-3 libreadline.



Bug#953006: [PATCH] Use current libreadline (Closes: #953006)

2020-04-03 Thread Bastian Germann
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 5487a85..06e9241 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: dbacl
 Section: text
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
-   libreadline-gplv2-dev,
+   libreadline-dev,
libslang2-dev,
libncurses-dev,
flex, bison
-- 
2.26.0



Bug#979101: Legally problematic GPL-3+ readline dependency

2021-01-02 Thread Bastian Germann

Package: devtodo
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.




Bug#998229: mazeofgalious: Website available under different URL

2021-11-01 Thread Bastian Germann

Source: mazeofgalious
Version: 0.62.dfsg2-4

The website is available at https://mog.jorito.net.
Please fix the homepage field and create a watch file.



Bug#1093528: nixnote2: Unmaintained upstream

2025-01-19 Thread Bastian Germann

Source: nixnote2
Version: 2.1.10+dfsg1-2
Severity: serious

nixnote2 is no longer developed according to upstream's README.
As it depends on obsolete QtWebKit unconditionally and it is orphaned I suggest this should be 
removed from Debian. As soon as this bug triggers autoremoval, I am going to file a remove request.

If you think this package should be kept in Debian, please voice your opinion 
here.



Bug#1093555: django-wkhtmltopdf: Keep out of testing

2025-01-19 Thread Bastian Germann

Source: django-wkhtmltopdf
Severity: serious
Version: 3.4.0-3

Please keep this outdated package out of testing.
This will help with getting wkhtmltopdf and subsequently qtwebkit out of 
testing.
I am going to file a removal bug for this package as soon as it is gone from 
testing.



Bug#1091999: parser3-cgi: Contains incompatible license combination

2025-01-03 Thread Bastian Germann
Package: parser3-cgi
Version: 3.4.5-1
Severity: serious

parser3-cgi and libapache2-mod-parser3 combine GPL licensed files with the 
RSA-MD licensed files in src/lib/md5.
RSA-MD is incompatible with any GPL version because of its advertisement clause:

"""
License is also granted to make and use derivative works provided   
 that such works are 
identified as "derived from the RSA Data
 Security, Inc. MD5 Message-Digest Algorithm" 
in all material 
mentioning or referencing the derived work.
"""

Also, the Apache-1.1 license used in those files is problematic with GPL.



Bug#1009317: singleapplication: Please provide Qt6 library

2025-03-17 Thread Bastian Germann
Control: tags -1 wontfix

Please check if you can use kdsingleapplication.
singleapplication will not receive any updates due to #1050520.



Bug#1102365: RM: zemberek-server -- RoQA; Orphaned; severely outdated; last mina-depending package

2025-04-08 Thread Bastian Germann
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: zemberek-ser...@packages.debian.org
Control: affects -1 + src:zemberek-server
Control: block -1 by 1102364
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove zemberek-server. It is orphaned and severely outdated. It
is the last pkg that depends on package mina. The popcon suggests that
it is not used anymore.



Bug#1102576: RM: lua-wsapi-fcgi -- RoQA; binary pkg not built anymore

2025-04-10 Thread Bastian Germann
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: lua-ws...@packages.debian.org
Control: affects -1 + src:lua-wsapi
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove lua-wsapi-fcgi which is no longer built by its source
package.



Bug#1102575: RM: lua-wsapi-fcgi-dev -- RoQA; binary pkg not built anymore

2025-04-10 Thread Bastian Germann
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: lua-ws...@packages.debian.org
Control: affects -1 + src:lua-wsapi
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove the binary package lua-wsapi-fcgi-dev which is no longer
built by its source package.



Bug#1100703: RM: singleapplication -- RoQA; orphaned; leaf package; new upstream versions non-free

2025-03-17 Thread Bastian Germann
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: singleapplicat...@packages.debian.org
Control: affects -1 + src:singleapplication
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove singleapplication from the archive. It is orphaned and a leaf
package (I have just got rid of the last rdep). Newer upstream versions
have a non-free license (#1050520), so Debian should not promote this
software by keeping it in the archive.



Bug#1102364: RM: zpspell -- ROM; Upstream dead; orphaned; low popcon

2025-04-10 Thread Bastian Germann
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: zpsp...@packages.debian.org
Control: affects -1 + src:zpspell
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove zpspell. Its upstream is not available anymore and it
seems to unused, judging by the popcon value. The package is orphaned.



Bug#1102709: libutf8.h-dev and libutfcpp-dev have an undeclared file conflict on /usr/include/utf8

2025-05-15 Thread Bastian Germann
X-Debbugs-CC: by...@debian.org

Hi Boyuan,

You have introduced the /usr/include/utf8 link in libutfcpp-dev, which
was after libutf8.h-dev already had that directory. Your changelog entry
says:

  * debian/libutfcpp-dev.maintscript, debian/libutfcpp-dev.links: Add
compat symlink to avoid breaking build-dependencies after upstream
moved header file paths.

Do you remember which packages were affected?

Thanks,
Bastian



Bug#1102709: libutf8.h-dev and libutfcpp-dev have an undeclared file conflict on /usr/include/utf8

2025-06-12 Thread Bastian Germann
Control: tags -1 patch

Even though libutf8.h-dev was the first to have this path in the
installed files, I suggest to modify libutf8.h-dev because it is not
used by any other Debian package and can easily change its file paths.

Please find a patch attached that installs the header file to a
different location.
>From 8d0221bbf13bb5ff8d3539697ffab0408d7b7355 Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Thu, 12 Jun 2025 08:19:57 +0200
Subject: [PATCH] Install header file in /usr/include/utf (Closes: #1102709)

---
 debian/libutf8.h-dev.install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libutf8.h-dev.install b/debian/libutf8.h-dev.install
index 4bdeedd..44f0fe9 100644
--- a/debian/libutf8.h-dev.install
+++ b/debian/libutf8.h-dev.install
@@ -1 +1 @@
-utf8.h	usr/include/utf8/
+utf8.h	usr/include/utf/


Bug#1109774: unblock: biboumi/9.0+20241124-2

2025-07-23 Thread Bastian Germann
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: bibo...@packages.debian.org
Control: affects -1 + src:biboumi
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package biboumi

[ Reason ]
Fix #1109758 to get rid of botan v2 dependency.

This change is meant to be a preparation for fixing #1109756.
Please consider raising the #1109756 severity so that the other
remaining blockers can be fixed until the full freeze.

[ Impact ]
This disables TLS for the package.
biboumi is the only blocking package that loses some functionality.

[ Tests ]
None.

[ Risks ]
Some people may use the TLS functionality. In general, this orphaned package
does not seem to be used a lot.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
You should only unblock this if you like to see botan gone from trixie.
I am going to hand in fixes/unblocks for the other blocking packages
then.

unblock biboumi/9.0+20241124-2



Bug#1109758: biboumi: Disable TLS to get rid of botan v2

2025-07-23 Thread Bastian Germann
Source: biboumi
Version: 9.0+20241124-1
Severity: normal
Control: block 1109756 by -1

Please replace Build-Depends: libbotan-2-dev with libgcrypt20-dev so
that botan (EOL) can be removed from the archive.



Bug#1109758: biboumi: Disable TLS to get rid of botan v2

2025-07-23 Thread Bastian Germann
Control: reopen -1

This was reverted, as requested by the Release Team.