Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
Am Dienstag, dem 14.05.2024 um 13:35 +0200 schrieb Tobias Frost: (forgotten cc, again, sorry) > However, recycling upstream version numbers (as upstream) should be > avoided, as there are now two 0.8.5 in the world. Please avoid that. Where did I recycle upstream version numbers? Which are the two 0.8.5s? Is it that upstream has moved and you consider 0.8.5-1 a 0.8.5? Sincerely, Joachim
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
(forgotten cc) Am Freitag, dem 03.05.2024 um 18:50 +0200 schrieb Tobias Frost: > reviewing your new package: > > - d/changelog > - generally documents only changes to the packaging, not "upstream" changes > (the entry "Fixed logrotate conf user name" is an upstream change.) > There are exceptions, like if it a very noteworthy change, but this > is one isn't in that category. > - When packaging a new upstream version, you say so in the changelog. > (Like first changelog entry: > * New upstream version. > ) > - There are undocumented changes, for example the change to the > Standard-Version. > Done. > A nitpick on d/rules: > I'm a fan of declarative syntax, so I'd replace the dh_clean override > with specifing the file to be deleted in the file d/clean. (If you feel > different about this, it is ok to ignore my nitpicking) Done, thx. > Remarks on Readme.md: > - It cointains only information not relevant when the user is > installing the binary package (like how to build, how to install and > where to find the packages), so it should not be installed into > the binary package. Not exactly. There is the important line "Our packages are built with MQTT support, but without OMS support.". In addition it is a moving target. So I'd prefer to keep it as now. > - "Debian" is written with a captial "D". Done. > - The sentence "Unfortunately Debian armhf packages do not > run on Raspberry Pi 1 although the architecture on the RPi is named armhf. > Using Raspian armhf packages fixes that." is a bit hard to parse, a > bit off: > - Raspberry Pi 1 is supported by the Debian armel architecture, so people > running (real) Debian on the Pi 1 need to use "armel" not "armhf". > - Paspian has been renamed to Raspberry Pi OS, so the naming should > maybe be also updated. Done. During the discussion more changes were added. > Maybe this should be separated into a Debian and Raspberry Pi OS > section? (They are different distributions anyways…) The handling is very similar from the users perspective. > > Some parts already mentioned for the previous upload, would be great if > you could start tackling them: > > As you are involved with upstream: > The manpage, initfile, systemd service file should probably be included in the > upstream part, it is not only useful for Debian alone. > It is currently under discussion if other installation methods are still needed. > Linitian: (I've pre-filtered them a bit already on those that should be > investigaged. If harderning is working now, override the linitian I: tag.) > I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:15] > I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] > I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] > P: vzlogger source: trailing-whitespace [debian/changelog:10] > P: vzlogger source: trailing-whitespace [debian/changelog:4] > P: vzlogger source: trailing-whitespace [debian/control:17] > P: vzlogger source: trailing-whitespace [debian/control:40] > P: vzlogger source: trailing-whitespace [debian/rules:45] > X: vzlogger: systemd-service-file-missing-hardening-features [usr/lib/systemd/system/vzlogger.service] > X: vzlogger source: upstream-metadata-file-is-missing All done except for upstream-metadata-file-is-missing. I don't think this is of much use for a service. An updated 0.8.5-1 has been uploaded. Sincerely, Joachim
Bug#1070430: vzlogger: logrotate exits with error after package removal
Am Sonntag, dem 05.05.2024 um 11:12 +0200 schrieb Andreas Beckmann: > Usually the solution is to specify 'missingok' in the logrotate > configuration. There is already a missingok in the configuration. So this is not causing it. > From the attached log (scroll to the bottom...): > > 0m27.6s DEBUG: Starting command: ['nsenter', > '--net=/run/netns/piuparts-netns-4', > '--uts=/srv/piuparts/tmp/tmprFiuJ6/ns-uts', 'chroot', > '/srv/piuparts/tmp/tmprFiuJ6/chroot', '/usr/sbin/logrotate', > '/etc/logrotate.d/vzlogger'] > 0m27.6s DUMP: > error: /etc/logrotate.d/vzlogger:7 unknown user 'vzlogger' > error: found error in /var/log/vzlogger.log , skipping > 0m27.6s ERROR: Command failed (status=1): ['nsenter', > '--net=/run/netns/piuparts-netns-4', > '--uts=/srv/piuparts/tmp/tmprFiuJ6/ns-uts', 'chroot', > '/srv/piuparts/tmp/tmprFiuJ6/chroot', '/usr/sbin/logrotate', > '/etc/logrotate.d/vzlogger'] Unfortunately the logrotate configuration had not been adapted when the service users name had been changed from vzlogger to _vzlogger. This will be fixed with the next upload. Thanks for the report, Joachim -- Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und archivieren Sie sie.
Bug#1059417: ed: diff for NMU version 1.20.1-1.1
Control: found -1 1.20.2-1 On 2024-04-17 14:26 +0200, Chris Hofstaedtler wrote: > Control: tags 1059417 + patch > Control: tags 1059417 + pending > > > Dear maintainer, > > I've prepared an NMU for ed (versioned as 1.20.1-1.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Seems your NMU was ignored and reverted in the latest upload. :-( Cheers, Sven > diff -Nru ed-1.20.1/debian/changelog ed-1.20.1/debian/changelog > --- ed-1.20.1/debian/changelog2024-02-17 12:12:41.0 +0100 > +++ ed-1.20.1/debian/changelog2024-04-17 14:22:21.0 +0200 > @@ -1,3 +1,12 @@ > +ed (1.20.1-1.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * Install ed, red into /usr/bin. (Closes: #1059417) > +Keep update-alternatives calls unchanged, to preserve existing > +user configuration. > + > + -- Chris Hofstaedtler Wed, 17 Apr 2024 14:22:21 +0200 > + > ed (1.20.1-1) unstable; urgency=medium > >* New upstream version 1.20.1 > diff -Nru ed-1.20.1/debian/rules ed-1.20.1/debian/rules > --- ed-1.20.1/debian/rules2024-02-17 12:12:41.0 +0100 > +++ ed-1.20.1/debian/rules2024-04-17 14:21:33.0 +0200 > @@ -12,7 +12,7 @@ > dh $@ > > override_dh_auto_configure: > - dh_auto_configure -- --bindir=/bin $(CROSS) \ > + dh_auto_configure -- $(CROSS) \ > $(foreach v,CPPFLAGS CFLAGS LDFLAGS,'$(v)=$($(v))') > > override_dh_auto_test:
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "vzlogger": * Package name : vzlogger Version : 0.8.5-1 Upstream contact : Joachim Zobel * URL : http://wiki.volkszaehler.org/software/controller/vzlogger * License : GPL-3.0-or-later * Vcs : https://github.com/volkszaehler/vzlogger/tree/debian Section : net The source builds the following binary packages: vzlogger - program for logging measurements of smart meters To access further information about this package, please visit the following URL: http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ Alternatively, you can download the package with 'dget' using this command: dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc Changes since the last upload: * Fixed logrotate conf user name * Fixed passing of hardening flags to cmake Regards, -- Joachim Zobel
Bug#1067539: Moved my depending packages to autopkgtest
Hi. My packages gap-polymaking and gap-hapcryst are now using autopkgtest. In both cases the FTBFS was caused by tests running as part of the build, so my problem is solved. Sincerely, Joachim
Bug#1068903: elpa-magit: missing dependency on elpa-transient (>= 0.5.0)
Package: elpa-magit Version: 3.3.0+git20231219.1.c7ab6931-1 Severity: serious After loading magit Emacs displayed the following message in the *Warnings* buffer: , | Emergency (magit): Magit requires ‘transient’ >= 0.5.0, | but due to bad defaults, Emacs’ package manager, refuses to | upgrade this and other built-in packages to higher releases | from GNU Elpa. ` Emacs' builtin version of transient is 0.4.3 which is too old, installing the elpa-transient package fixed the problem. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.85-nouveau (SMP w/2 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) Versions of packages elpa-magit depends on: ii dh-elpa-helper 2.0.17 ii elpa-compat 29.1.4.5+dfsg-1 ii elpa-dash 2.19.1+git20220608.1.0ac1ecf+dfsg-1 ii elpa-git-commit 3.3.0+git20231219.1.c7ab6931-1 ii elpa-magit-section 3.3.0+git20231219.1.c7ab6931-1 ii elpa-seq2.24-1 ii elpa-with-editor3.3.2-1 ii emacsen-common 3.0.5 ii git 1:2.43.0-1+b1 elpa-magit recommends no packages. elpa-magit suggests no packages. -- no debconf information
Bug#1065806: pam: recent upgrade changes previous default umask
On 2024-04-08 14:13 -0600, Sam Hartman wrote: >> "Professor" == Professor Jeebs writes: > > > Professor> I prefer the way it is handled per user. There is a related, > commented > Professor> out, option in /etc/skel/.profile, which lands in new user > directories, > Professor> which I have never touched the umask part until now. I > uncommented the > Professor> line to set the users' default umask settings to 022 and > updated users > Professor> already on the system. > > > Just confirming. You could have modified /etc/login.defs if you chose > and gotten a similar affect, right? I think the file to edit is actually /etc/pam.d/common-session, adding the "nousergroups" option in the line with pam_umask.so. That is what I did after reading the pam_umask(8) manpage. Cheers, Sven
Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages
On 2024-04-08 15:46 +0200, Chris Hofstaedtler wrote: > To clarify, because I think there is still some ongoing > confusion regarding binary files and binary packages, here a table: > > Debian package name | (primary) file(s) > > liblastlog2-0| /usr/lib/.../liblastlog2.so.* > libpam-lastlog2 | /usr/lib/.../pam_lastlog2.so > lastlog2 | /usr/bin/lastlog2 (probably + symlink "last") I think you mean "lastlog" rather than "last" here, the latter displays wtmp entries. > I think my biggest open questions for the packaging itself are: > > * Which package will pull in lastlog2 and libpam-lastlog2, for > for upgrades from bookworm? If lastlog2 takes over the lastlog binary, the logical package seems to be login which is currently shipping it. The only question is if it that should be done via Depends or Recommends, I would prefer the latter to avoid pulling in libsqlite3 in every container/chroot. > * Should /usr/bin/lastlog2 be in a separate lastlog2 package or not? It could be in its own package or in util-linux-extra, I have no particular preference. > * Should lastlog2 Depend: libpam-lastlog2? Vice versa? Only > Recommends? I think lastlog2 needs to depend on libpam-lastlog2, because it is not useful otherwise. There may be a few cornercases such as having installed lastlog2 and login or sshd from different architectures, but then the local admin should know what they are doing and install libpam-lastlog2 for all architectures. There does not seem to be any particular reason why libpam-lastlog2 should recommend lastlog2. Cheers, Sven
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2024-04-06 21:45 +0200, Santiago Vila wrote: > El 6/4/24 a las 20:53, Sven Joachim escribió: >> 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11 > > Ok, I had not read that part of Policy in a long time. > > One minor last thing: > > Assuming I make the changes and package the new available > upstream version at the same time, can I simplify the breaks > and replaces to just "(<< 1.3-20240307)"? Yes, that should be fine. Cheers, Sven
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2024-04-06 19:49 +0200, Santiago Vila wrote: >> Patch attached, I have tested that it builds on amd64 and i386. looked >> at the generated Dependencies and verified that lintian does not go >> crazy, but that's it. Note that I had to add libtool-bin rather than >> just libtool to Build-Depends to prevent configure from complaining, and >> also pacify dh_missing considering the not installed .la file. > > Awesome, thanks a lot! > > Regarding the static library, I can see now that keeping it does not > really make the package more complex, so we'll keep it. > > A few questions: > > - Does this require a "transition"? I think not, because the API has not > changed. On the other hand, packages which build-depend on libdialog-dev > should be rebuilt with the shared library anyway, and this is usually done > as part of a transition. Considering that there are currently no packages in unstable which build-depend on libdialog-dev (or on dialog, for that matter), a transition seems unnecessary. > - Regarding the Breaks field, I think it's not actually required and > we should not add it (i.e. Replaces is enough). Policy disagrees, and the piuparts maintainer might come after you if they detect that. > I tried creating the packages without the Breaks field, installing the > libdialog and libdialog-dev packages on a system where dialog was > already installed, and this is what happened: > > # dpkg -i libdialog-dev_1.3-20240101-2_amd64.deb > libdialog15_1.3-20240101-2_amd64.deb > (Reading database ... 14174 files and directories currently installed.) > Preparing to unpack libdialog-dev_1.3-20240101-2_amd64.deb ... > Unpacking libdialog-dev:amd64 (1.3-20240101-2) ... > Replacing files in old package dialog (1.3-20240101-1) ... > Preparing to unpack libdialog15_1.3-20240101-2_amd64.deb ... > Unpacking libdialog15:amd64 (1.3-20240101-2) over (1.3-20240101-2) ... > Setting up libdialog15:amd64 (1.3-20240101-2) ... > Setting up libdialog-dev:amd64 (1.3-20240101-2) ... > Processing triggers for man-db (2.12.1-1) ... > Not building database; man-db/auto-update is not 'true'. > Processing triggers for libc-bin (2.37-15.1) ... > > i.e. no errors, dpkg takes note of the moved files, and the old dialog > is still functional, because it's still linked statically. Yes, but if you then decide to remove the libdialog-dev package, the libdialog.a file is gone, although the old dialog package supposedly still provides libdialog-dev. That is the reason why Policy recommends to use "Replaces" in combination with "Breaks"[1]. Cheers, Sven 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11
Bug#1068495: sponsorship-requests: RFS: tack/1.09+20230201-1 [RC] -- terminfo action checker
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "tack": * Package name : tack Version : 1.09+20230201-1 Upstream contact : Thomas Dickey * URL : https://invisible-island.net/ncurses/tack.html * License : GPL-2+ * Vcs : https://salsa.debian.org/joachim-guest/tack Section : misc The source builds the following binary packages: tack - terminfo action checker To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tack/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tack/tack_1.09+20230201-1.dsc Changes since the last upload: tack (1.09+20230201-1) unstable; urgency=medium . [ Debian Janitor ] * Use secure copyright file specification URI. * Bump debhelper from old 10 to 13. * Set debhelper-compat version in Build-Depends. * Fix field name case in debian/copyright (Upstream-name => Upstream-Name). * Use canonical URL in Vcs-Browser. * Fix field name case in debian/copyright (Upstream-contact ⇒ Upstream-Contact). . [ Sven Joachim ] * New upstream snapshot. - Fixes FTBFS with -Werror=implicit-function-declaration (Closes: #1066469). * Update debian/watch to version 4, and look for tarballs on https://invisible-mirror.net. * Add a debian/watch.snapshot file for checking/downloading snapshots with uscan. * Update debian/upstream/signing-key.asc. - Add new key 19882D92DDA4C400C22C0D56CC2AF4472167BE03. - Drop old SHA1 key C52048C0C0748FEE. * Build-depend on libncurses-dev rather than on libncurses5-dev. * Bump Standards-Version to 4.6.2, no changes needed. * Update debian/copyright. * Add a debian/salsa-ci.yml file for the Salsa CI pipeline. - Disable the arm64 crossbuild job, not supported. Some additional notes: the latest stable upstream release (1.09) of tack is already over four years old and does not contain a fix for the FTBFS bug #1066469. I have asked for a 1.10 release, but since that has not come forth yet, I decided to package the latest snapshot instead. There a no reverse dependencies and very few users, so the risk should be low. I have not yet finalized debian/changelog and tagged a release on Salsa to prevent confusion in case additional modifications are needed. Will do that once the package is accepted in the archive. Cheers, Sven signature.asc Description: PGP signature
Bug#1064589: marked as done (RFS: photodedupe/1.0.1 [ITP] -- a utility for identifying duplicate images)
Am Freitag, dem 05.04.2024 um 19:18 + schrieb Debian Bug Tracking System: > You need to provide a proper source package, not a dpkg-deb artifact. Learning about debcargo might be helpful. Sincerely, Joachim https://salsa.debian.org/rust-team/debcargo/ -- Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und archivieren Sie sie.
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
On 2024-04-03 22:47 +0200, Alejandro Colomar wrote:
> On Wed, Apr 03, 2024 at 06:01:50PM +0200, Sven Joachim wrote:
>> Control: severity -1 normal
>>
>> On 2024-04-03 11:29 +0200, Alejandro Colomar wrote:
>>
>> > I now see that `apt-file show glibc-doc` shows several more pages. I'll
>> > have a look at them and maybe I also import them into the Linux
>> > man-pages project.
>>
>> AFAICS all of them have already been added there, right?
>
> Nope; I added the ones that I found in upstream glibc, and then I
> upgraded them to the version they had in Debian. But for some reason, I
> didn't notice that there were more in Debian. Or maybe I thought they
> were already in the Linux man-pages. Whatever the reason, they're not
> there.
>
> See:
>
> $ diff -u \
> <(apt-file show glibc-doc \
> | awk '{print $2}' \
> | grep /man/ \
> | sed 's,^/usr/share/man/,,' \
> | sed 's/\.gz$//' \
> | sort) \
> <(find src/linux/man-pages/man-pages/master/man* -type f \
> | sed 's,^src/linux/man-pages/man-pages/master/,,' \
> | sort) \
> | grep ^-;
> --- /dev/fd/632024-04-03 22:40:00.524652442 +0200
> -man3/pthread_cond_broadcast.3
> -man3/pthread_cond_destroy.3
> -man3/pthread_cond_signal.3
> -man3/pthread_cond_timedwait.3
> -man3/pthread_cond_wait.3
> -man3/pthread_condattr_destroy.3
> -man3/pthread_getspecific.3
> -man3/pthread_key_delete.3
> -man3/pthread_mutex_destroy.3
> -man3/pthread_mutex_lock.3
> -man3/pthread_mutex_trylock.3
> -man3/pthread_mutex_unlock.3
> -man3/pthread_mutexattr_getkind_np.3
> -man3/pthread_mutexattr_gettype.3
> -man3/pthread_mutexattr_settype.3
> -man3/pthread_setspecific.3
Those are not additional pages, but just symlinks.
,
| $ file $(dpkg -L glibc-doc | tail -n17)
| /usr/share/man/man3/pthread_cond_broadcast.3.gz: symbolic link to
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_destroy.3.gz: symbolic link to
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_signal.3.gz: symbolic link to
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_timedwait.3.gz: symbolic link to
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_cond_wait.3.gz:symbolic link to
pthread_cond_init.3.gz
| /usr/share/man/man3/pthread_condattr_destroy.3.gz: symbolic link to
pthread_condattr_init.3.gz
| /usr/share/man/man3/pthread_getspecific.3.gz: symbolic link to
pthread_key_create.3.gz
| /usr/share/man/man3/pthread_key_delete.3.gz: symbolic link to
pthread_key_create.3.gz
| /usr/share/man/man3/pthread_mutex_destroy.3.gz:symbolic link to
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutex_lock.3.gz: symbolic link to
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutex_trylock.3.gz:symbolic link to
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutex_unlock.3.gz: symbolic link to
pthread_mutex_init.3.gz
| /usr/share/man/man3/pthread_mutexattr_destroy.3.gz:symbolic link to
pthread_mutexattr_init.3.gz
| /usr/share/man/man3/pthread_mutexattr_getkind_np.3.gz: symbolic link to
pthread_mutexattr_setkind_np.3.gz
| /usr/share/man/man3/pthread_mutexattr_gettype.3.gz:symbolic link to
pthread_mutexattr_init.3.gz
| /usr/share/man/man3/pthread_mutexattr_settype.3.gz:symbolic link to
pthread_mutexattr_init.3.gz
| /usr/share/man/man3/pthread_setspecific.3.gz: symbolic link to
pthread_key_create.3.gz
`
In the man-pages source such aliases are included as files just
containing a .so directive, those should indeed be added.
> I'll import those into the Linux man-pages in a week, when I get back
> from vacation.
Have a nice vacation!
Cheers,
Sven
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
Control: severity -1 normal On 2024-04-03 11:29 +0200, Alejandro Colomar wrote: > Hi, > > On Tue, Apr 02, 2024 at 08:58:32PM +0200, Aurelien Jarno wrote: >> Thanks, that sounds great that we can finally get rid out of those in >> the debian package. >> >> >$ git diff --stat b06cd070f..128a3ae35 >> > man3/pthread_cond_init.3| 264 >> > man3/pthread_condattr_init.3| 48 >> > man3/pthread_key_create.3 | 178 + >> > man3/pthread_mutex_init.3 | 241 ++ >> > man3/pthread_mutexattr_setkind_np.3 | 52 >> > man3/pthread_once.3 | 44 >> > 6 files changed, 827 insertions(+) > > I now see that `apt-file show glibc-doc` shows several more pages. I'll > have a look at them and maybe I also import them into the Linux > man-pages project. AFAICS all of them have already been added there, right? >> > Debian's manpages-dev_6.7-1_all.deb has been the first package since >> > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to >> > upgrade manpages-dev due to a conflict with glibc-doc. >> > >> >$ sudo apt-get upgrade -V; >> >[...] >> >Do you want to continue? [Y/n] y >> >Reading changelogs... Done >> >(Reading database ... 404853 files and directories currently installed.) >> >Preparing to unpack .../manpages-dev_6.7-1_all.deb ... >> >Unpacking manpages-dev (6.7-1) over (6.05.01-1) ... >> >dpkg: error processing archive >> > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack): >> > trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', >> > which is also in package glibc-doc 2.38-6 >> >Errors were encountered while processing: >> > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb >> >needrestart is being skipped since dpkg has failed >> >E: Sub-process /usr/bin/dpkg returned an error code (1) >> >> I think this is actually not specific to the experimental version, those >> manpages are also in the unstable version. > > Right. I only installed the experimental one to see if the bug had > been fixed (as reportbug(1) suggested trying it). > >> > Please, remove from glibc-doc those manual pages that conflict with >> > manpages-dev. >> >> Noted. However following the time_t transition, the glibc package does >> not build anymore on 32-bit architectures (i have just opened #1059937 >> to make people aware of that), so uploading a new glibc now is probably >> not the best idea. > > Hmm, maybe you can drop the manual pages, but not upload yet, and wait > for that bug to be fixed to do an upload without the pages. Note that manpages-dev 6.7-2 has dropped the clashing files for the time being. I do not think there is any need to hurry, so I am downgrading the severity of this bug. Whenever the glibc-doc package in unstable drops the manpages, we should file a bug against manpages-dev to include them again. Cheers, Sven
Bug#1068243: bsdgames: fails to configure
Package: bsdgames Version: 2.17-31 Severity: serious Your package fails to configure in a fresh installation (but not when upgrading from a previous version). This is what happens in a throwaway chroot (unrelated lines stripped from apt/dpkg output): , | # apt install bsdgames | Selecting previously unselected package bsdgames. | Preparing to unpack .../bsdgames_2.17-31_amd64.deb ... | Unpacking bsdgames (2.17-31) ... | Setting up bsdgames (2.17-31) ... | cp: cannot stat '/usr/share/games/bsdgames/phantasia/void': No such file or directory | dpkg: error processing package bsdgames (--configure): | installed bsdgames package post-installation script subprocess returned error exit status 1 | Errors were encountered while processing: | bsdgames | E: Sub-process /usr/bin/dpkg returned an error code (1) ` See also the Salsa CI job at [1]. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 1. https://salsa.debian.org/games-team/bsdgames/-/jobs/5528281
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
On 2024-04-01 19:02 +0200, Alejandro Colomar wrote: > Hi Sven, > > On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote: >> Makes perfect sense, but at the moment it can only be uploaded to >> experimental. >> >> > We're not in a freeze, so I guess that's fair game. >> >> We're not in a freeze but in the middle of the largest transition in >> Debian history[1], and during that a new major glibc version in unstable is >> out of the question. >> >> >> files for now and re-include either when glibc 2.38 is in unstable or >> >> when it is in testing. >> > >> > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch >> > dropped? Does 2.38 have any freeze at the moment? >> >> Yes. Every new major glibc version requires a transition (requiring >> rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other >> things), and the one for glibc 2.38[2] has been pending for three >> months[3]. > > Hmmm, I understand. If you want to temporarily drop these pages from > manpages-dev, go ahead. Please undrop them when glibc-doc can make a > new release. BTW, I guess glibc-doc must match libc6 version? It is built from the same source package, so yes. Cheers, Sven
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
On 2024-04-01 18:00 +0200, Alejandro Colomar wrote: > Hi Sven, > > On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote: >> Obviously the manpages-dev package should not have shipped these files >> as long as there are in glibc-doc; this is tracked in #1068166. > > I CCed back in 2023-10 the debian-glibc@ list notifying that these pages > were absorbed into the Linux man-pages project. They didn't respond. Thanks. That might have fallen through the cracks. >> Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good, >> because that version is only in experimental and will remain there for >> several weeks if not months. I think manpages-dev should drop these > > Why not add glibc-doc 2.38-7 dropping the patch that adds these pages? Makes perfect sense, but at the moment it can only be uploaded to experimental. > We're not in a freeze, so I guess that's fair game. We're not in a freeze but in the middle of the largest transition in Debian history[1], and during that a new major glibc version in unstable is out of the question. >> files for now and re-include either when glibc 2.38 is in unstable or >> when it is in testing. > > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch > dropped? Does 2.38 have any freeze at the moment? Yes. Every new major glibc version requires a transition (requiring rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other things), and the one for glibc 2.38[2] has been pending for three months[3]. >> There is also the problem that some derivatives (most notably Ubuntu) >> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces >> versions in manpages-dev accordingly. > > Hmmm. I suggest they patch glibc-doc to remove those manual pages. > They have been unsupported for a long time. The last change in > glibc-doc is from 2013. I guess Ubuntu can then drop the glibc-doc package entirely, as they do not ship the upstream changelogs in it, and after dropping the pthread_* manpages the package would be empty. TBH, I do not see much value in these changelogs and will probably uninstall glibc-doc from my systems. Cheers, Sven 1. https://lists.debian.org/debian-devel-announce/2024/02/msg5.html 2. https://release.debian.org/transitions/html/glibc-2.38.html 3. https://bugs.debian.org/1059852
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
On 2024-04-01 16:23 +0200, Alejandro Colomar wrote: > Package: glibc-doc > Version: 2.38-6 > Severity: serious > Justification: Policy 7.4 > X-Debbugs-Cc: a...@kernel.org, mar...@debian.org > > Dear Maintainer, > > The Linux man-pages project has recently added the pthread_*(3) manual > pages that were provided by glibc-doc. The first upstream version of > the Linux man-pages that includes these pages is man-pages-6.06. Here's > what was added: > > $ git diff --stat b06cd070f..128a3ae35 >man3/pthread_cond_init.3| 264 >man3/pthread_condattr_init.3| 48 >man3/pthread_key_create.3 | 178 + >man3/pthread_mutex_init.3 | 241 ++ >man3/pthread_mutexattr_setkind_np.3 | 52 >man3/pthread_once.3 | 44 >6 files changed, 827 insertions(+) > > Debian's manpages-dev_6.7-1_all.deb has been the first package since > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to > upgrade manpages-dev due to a conflict with glibc-doc. > $ sudo apt-get upgrade -V; > [...] > Do you want to continue? [Y/n] y > Reading changelogs... Done > (Reading database ... 404853 files and directories currently installed.) > Preparing to unpack .../manpages-dev_6.7-1_all.deb ... > Unpacking manpages-dev (6.7-1) over (6.05.01-1) ... > dpkg: error processing archive > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack): >trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', > which is also in package glibc-doc 2.38-6 > Errors were encountered while processing: >/var/cache/apt/archives/manpages-dev_6.7-1_all.deb > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) Obviously the manpages-dev package should not have shipped these files as long as there are in glibc-doc; this is tracked in #1068166. > Please, remove from glibc-doc those manual pages that conflict with > manpages-dev. Considering that the manpages in glibc-doc are not included upstream and created via a Debian patch, that makes a lot of sense. I was not aware of that fact. > Marcos, you'll also need to specify a breaks with glibc-doc versions > up to (and including) 6.38-6 in the next revision of manpages-dev, and > drop 6.7-1. Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good, because that version is only in experimental and will remain there for several weeks if not months. I think manpages-dev should drop these files for now and re-include either when glibc 2.38 is in unstable or when it is in testing. There is also the problem that some derivatives (most notably Ubuntu) are already shipping glibc 2.39 and will have to adjust Breaks/Replaces versions in manpages-dev accordingly. Thoughts? Cheers, Sven
Bug#1068166: manpages-dev: Fails to upgrade due to file conflict
Control: tags -1 + patch On 2024-04-01 06:41 +0200, Sven Joachim wrote: > Control: notfound -1 6.05.01-1 > Control: found -1 6.7-1 > > On 2024-04-01 06:17 +0200, Bas Couwenberg wrote: > >> Source: manpages >> Version: 6.05.01-1 >> Severity: serious >> Justification: makes the package in question unusable or mostly so >> >> Dear Maintainer, >> >> manpages-dev failed to upgrade due to a conflict with glibc-doc: >> >> Unpacking manpages-dev (6.7-1) over (6.05.01-1) ... >> dpkg: error processing archive >> /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack): >> trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', which is >> also in package glibc-doc 2.37-15.1 >> Errors were encountered while processing: >> /var/cache/apt/archives/manpages-dev_6.7-1_all.deb >> E: Sub-process /usr/bin/dpkg returned an error code (1) > > There are a few more conflicting files: > > , > | # dpkg -i --force-overwrite > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb > | (Reading database ... 15705 files and directories currently installed.) > | Preparing to unpack .../manpages-dev_6.7-1_all.deb ... > | Unpacking manpages-dev (6.7-1) ... > | dpkg: warning: overriding problem because --force enabled: > | dpkg: warning: trying to overwrite > | '/usr/share/man/man3/pthread_cond_init.3.gz', which is also in > | package glibc-doc 2.37-15.1 > | dpkg: warning: overriding problem because --force enabled: > | dpkg: warning: trying to overwrite > | '/usr/share/man/man3/pthread_condattr_init.3.gz', which is also in > | package glibc-doc 2.37-15.1 > | dpkg: warning: overriding problem because --force enabled: > | dpkg: warning: trying to overwrite > | '/usr/share/man/man3/pthread_key_create.3.gz', which is also in > | package glibc-doc 2.37-15.1 > | dpkg: warning: overriding problem because --force enabled: > | dpkg: warning: trying to overwrite > | '/usr/share/man/man3/pthread_mutex_init.3.gz', which is also in > | package glibc-doc 2.37-15.1 > | dpkg: warning: overriding problem because --force enabled: > | dpkg: warning: trying to overwrite > | '/usr/share/man/man3/pthread_mutexattr_setkind_np.3.gz', which is > | also in package glibc-doc 2.37-15.1 > | dpkg: warning: overriding problem because --force enabled: > | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_once.3.gz', > which is also in package glibc-doc 2.37-15.1 > ` > >> Breaks/Replaces will need to be added if the file was moved, but it >> seems that only one of these packages should include this manpage. > > There is a script debian/check-conflicts in the manpages source package > which is supposed to detect such clashing files, but it is buggy because > it only scans the contents of amd64 packages, while glibc-doc is an > arch:all package. Looking closer the script most likely worked correctly when it was written, but some 3+ years ago the Contents files were split. https://lists.debian.org/debian-devel-announce/2020/10/msg7.html I have updated debian/check-conflicts accordingly, and my version catches the six new clashing files :-). Merge request at Salsa opened: https://salsa.debian.org/debian/manpages/-/merge_requests/7 Cheers, Sven
Bug#1068166: manpages-dev: Fails to upgrade due to file conflict
Control: notfound -1 6.05.01-1 Control: found -1 6.7-1 On 2024-04-01 06:17 +0200, Bas Couwenberg wrote: > Source: manpages > Version: 6.05.01-1 > Severity: serious > Justification: makes the package in question unusable or mostly so > > Dear Maintainer, > > manpages-dev failed to upgrade due to a conflict with glibc-doc: > > Unpacking manpages-dev (6.7-1) over (6.05.01-1) ... > dpkg: error processing archive > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack): > trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', which is > also in package glibc-doc 2.37-15.1 > Errors were encountered while processing: > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) There are a few more conflicting files: , | # dpkg -i --force-overwrite /var/cache/apt/archives/manpages-dev_6.7-1_all.deb | (Reading database ... 15705 files and directories currently installed.) | Preparing to unpack .../manpages-dev_6.7-1_all.deb ... | Unpacking manpages-dev (6.7-1) ... | dpkg: warning: overriding problem because --force enabled: | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', which is also in package glibc-doc 2.37-15.1 | dpkg: warning: overriding problem because --force enabled: | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_condattr_init.3.gz', which is also in package glibc-doc 2.37-15.1 | dpkg: warning: overriding problem because --force enabled: | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_key_create.3.gz', which is also in package glibc-doc 2.37-15.1 | dpkg: warning: overriding problem because --force enabled: | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_mutex_init.3.gz', which is also in package glibc-doc 2.37-15.1 | dpkg: warning: overriding problem because --force enabled: | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_mutexattr_setkind_np.3.gz', which is also in package glibc-doc 2.37-15.1 | dpkg: warning: overriding problem because --force enabled: | dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_once.3.gz', which is also in package glibc-doc 2.37-15.1 ` > Breaks/Replaces will need to be added if the file was moved, but it > seems that only one of these packages should include this manpage. There is a script debian/check-conflicts in the manpages source package which is supposed to detect such clashing files, but it is buggy because it only scans the contents of amd64 packages, while glibc-doc is an arch:all package. Cheers, Sven
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2024-03-30 12:38 +0100, Santiago Vila wrote:
> El 30/3/24 a las 9:43, Sven Joachim escribió:
>> I think it would make sense for Debian to follow what Arch and Fedora
>> are doing, introduce a libdialog15 package with the shared library and a
>> libdialog-dev package with the .so symlink but without libdialog.a,
>> because that requires (if I understood you correctly) configuring and
>> building dialog twice, greatly complicating packaging.
>> Santiago, do you think this is a good plan?
>
> Yes. If we can avoid the static library to keep it simple, that would be
> better.
>
> Simple question: Is that really allowed these days? I wanted to be sure
> by reading Policy but did not find any statement saying they are required
> or not.
I could only find the following two sentences in §8.3:
,
| The static library ("libraryname.a") is usually provided in addition
| to the shared version. It is placed into the development package (see
| below).
`
So shipping static libraries is recommended but not required, and there
are certainly quite a few packages where upstream does not support them.
But see below.
>> I can work on an updated patch.
>
> That would definitely help.
This afternoon I got my hands dirty. The first attempt to simply pass
--with-shared to configure failed to give me a libdialog.a, and it also
produced the following odd collection of *.so* files:
libdialog.so -> libdialog.so.15.0.0
libdialog.so.1.3
libdialog.so.15.0.0 -> libdialog.so.1.3
Not what you would expect, and it does not match the files shipped in
the Fedora and Arch packages. A closer look revealed that they both
configure dialog --with-libtool, and that worked great because it gave
me not only the expected layout of *.so* files, but also a static
libdialog.a library. :-)
Patch attached, I have tested that it builds on amd64 and i386. looked
at the generated Dependencies and verified that lintian does not go
crazy, but that's it. Note that I had to add libtool-bin rather than
just libtool to Build-Depends to prevent configure from complaining, and
also pacify dh_missing considering the not installed .la file.
There are certainly a few improvements possible (e.g. adding a symbols
file, testing R³ support), I leave this up to you.
Cheers,
Sven
diff -Nru dialog-1.3-20240101/debian/changelog dialog-1.3-20240101/debian/changelog
--- dialog-1.3-20240101/debian/changelog 2024-01-23 18:05:00.0 +0100
+++ dialog-1.3-20240101/debian/changelog 2024-03-30 19:21:27.0 +0100
@@ -1,3 +1,11 @@
+dialog (1.3-20240101-2) UNRELEASED; urgency=medium
+
+ * Split out libdialog-dev into its own package. Closes: #1012325.
+ * Build a shared library.
+ * Add libtool-bin to Build-Depends.
+
+ -- Sven Joachim Sat, 30 Mar 2024 19:21:27 +0100
+
dialog (1.3-20240101-1) unstable; urgency=medium
* New upstream release.
diff -Nru dialog-1.3-20240101/debian/control dialog-1.3-20240101/debian/control
--- dialog-1.3-20240101/debian/control 2024-01-23 17:00:00.0 +0100
+++ dialog-1.3-20240101/debian/control 2024-03-30 19:21:27.0 +0100
@@ -3,13 +3,12 @@
Priority: optional
Maintainer: Santiago Vila
Standards-Version: 4.6.2
-Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3)
+Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3), libtool-bin
Homepage: https://invisible-island.net/dialog/dialog.html
Package: dialog
Architecture: any
Depends: debianutils (>= 1.6), ${misc:Depends}, ${shlibs:Depends}
-Provides: libdialog-dev
Multi-Arch: foreign
Description: Displays user-friendly dialog boxes from shell scripts
This application provides a method of displaying several different types
@@ -29,3 +28,29 @@
tail Allows viewing the end of files (tail) that auto updates
background tail Similar to tail but runs in the background.
editbox Allows editing an existing file
+
+Package: libdialog15
+Architecture: any
+Section: libs
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Multi-Arch: same
+Description: Displays user-friendly dialog boxes -- shared library
+ The dialog application provides a method of displaying several different
+ types of dialog boxes from shell scripts. This allows a developer of a
+ script to interact with the user in a much friendlier manner.
+ .
+ This package contains the shared library.
+
+Package: libdialog-dev
+Architecture: any
+Section: libdevel
+Depends: ${misc:Depends}, libdialog15 (= ${binary:Version}), libncurses-dev
+Multi-Arch: same
+Replaces: dialog (<< 1.3-20240101-2~)
+Breaks: dialog (<< 1.3-20240101-2~)
+Description: Displays user-friendly dialog boxes -- development files
+ The dialog application provides a method of displaying several different
+ types of dialog boxes from shell scripts. This allows a developer of a
+ script to interact with the user in a much friendlier manner.
+ .
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2023-01-05 20:32 -0500, Thomas Dickey wrote: > - Original Message - > | From: "Santiago Vila" > | To: "Thomas Dickey" , 1012...@bugs.debian.org > | Cc: "Sven Joachim" > | Sent: Thursday, January 5, 2023 7:09:22 PM > | Subject: Bug#1012325: dialog: Multi-Arch: foreign package should not > contain static library > > | El 6/1/23 a las 0:39, Thomas Dickey escribió: > |> On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote: > |>> In Debian the static library has always been named libdialog.a, > |>> but the library according to the author is called libcdialog.so. > |> > |> A development package could have both static and dynamic libraries. > |> dialog can build either, but not both at the same time (just like ncurses). > | > | Ok, I didn't know, but the thing which I'm worried about is > | really libdialog vs libcdialog, not ".a" vs ".so". > > I name my Dialog package with a "c" to allow me to have > both the Debian and my test-package installed without conflict. > > (I do this for most of my test-packages, because it's otherwise awkward to > respond to bug-reports) > > My comment about the layout was in more general terms, > to show how it might be reorganized to provide the development library. I had a look at the dialog package list for Arch Linux[1] and Fedora Rawhide[2], and they both ship libdialog.so, libdialog.so.15 and libdialog.so.15.0.0. There is no libcdialog.so, nor a static library. > | (sorry for mixing both things) > | > | To be more precise: Are there any applications in the wild linked > | against libcdialog.so which would not run in a Debian system > | if I decide to provide libdialog.so in the Debian package? > > very few people (aside from me) use my test-packages :-) I think it would make sense for Debian to follow what Arch and Fedora are doing, introduce a libdialog15 package with the shared library and a libdialog-dev package with the .so symlink but without libdialog.a, because that requires (if I understood you correctly) configuring and building dialog twice, greatly complicating packaging. Santiago, do you think this is a good plan? I can work on an updated patch. Cheers, Sven 1. https://archlinux.org/packages/core/x86_64/dialog/ 2. https://fedora.pkgs.org/rawhide/fedora-x86_64/dialog-1.3-50.20240101.fc40.x86_64.rpm.html
Bug#1068017: util-linux: please ship liblastlog2 packages
On 2024-03-29 20:36 -0700, Steve Langasek wrote: > On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote: >> Hi OpenSSH, shadow Maintainers, >> >> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote: >> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote: >> > > It seems desirable to ship liblastlog2 in trixie, considering that the >> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already >> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer >> > > recorded in /var/log/lastlog. > >> [..] >> > At the same time, all traditional writing to /var/log/lastlog should >> > stop. Not sure why that would need to happen at the same time, unless there are plans to import the contents of the lastlog file into the liblastlog2 database on its first installation. >> > So, after some of the current fog clears, src:util-linux could >> > introduce new binary packages (at least libpam-lastlog2), but >> > src:pam would need to add it to the common-* config files. > >> > Does this seem right? > >> Answering my own question, not quite. > >> Apparently, traditionally we have: > >> * sshd writes to /var/log/lastlog by itself. >> * login has pam_lastlog.so in its PAM snippet. > >> Both of these would need to be replaced by pam_lastlog2.so. I don't >> really know what the other distros are doing right now, and/or if >> we should align on this. I suppose that openSUSE will do that soon, they have already replaced /var/log/wtmp with wtmpdb, written by the same author as liblastlog2. >> So we could either put pam_lastlog2.so into a common-* file from >> src:pam, or openssh and shadow should switch their setup. > >> What do we all think about that? > > pam should not be adding any modules to common-* that it itself does not > ship. Instead they should be added via pam-auth-config. I think you mean pam-auth-update here. Cheers, Sven
Bug#1068017: util-linux: please ship liblastlog2 packages
Source: util-linux Version: 2.40~rc2-8 Severity: wishlist It seems desirable to ship liblastlog2 in trixie, considering that the /var/log/lastlog file is not Y2038-safe and pam in unstable has already dropped pam_lastlog.so, meaning that non-ssh logins are no longer recorded in /var/log/lastlog. I have not looked closely yet, but I guess that would mean additional packages liblastlog2-2 for the library, liblastlog2-dev for the development files and libpam-lastlog2 for the pam module. The lastlog2 binary could probably be included in util-linux-extra.
Bug#1067860: dh-debputy: conffiles are not registered
Package: dh-debputy
Version: 0.1.22
Severity: important
Retrying xterm with dh-debputy (see
https://salsa.debian.org/joachim-guest/xterm/-/tree/debputy?ref_type=heads)
I noticed that no conffiles are registered, although xterm ships various
files in /etc:
,
| $ debdiff /var/cache/apt/archives/xterm_390-1+b1_amd64.deb
xterm_390-1+debputy1_amd64.deb
| [The following lists of changes regard files as different if they have
| different names, permissions or owners.]
|
| Files in first .deb but not in second
| -
| -rw-r--r-- root/root /usr/share/doc/xterm/changelog.Debian.amd64.gz
| -rw-r--r-- root/root DEBIAN/conffiles
|
| Control files: lines which differ (wdiff format)
|
| Installed-Size: [-2452-] {+2450+}
| [-Source: xterm (390-1)-]
| Version: [-390-1+b1-] {+390-1+debputy1+}
`
This seems to have regressed since my previous attempt with debputy
0.1.9 (see #1057001).
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Versions of packages dh-debputy depends on:
ii debhelper 13.15.2
ii man-db2.12.0-3+b1
ii perl 5.38.2-3.2
ii python3 3.11.8-1
ii python3-colored 2.2.3-1
ii python3-colorlog 6.8.2-1
ii python3-debian0.1.49
ii python3-ruamel.yaml 0.17.21-1
ii strip-nondeterminism 1.13.1-1
Versions of packages dh-debputy recommends:
ii python3-argcomplete 3.1.4-1
Versions of packages dh-debputy suggests:
ii hunspell-en-us 1:2020.12.07-2
pn python3-hunspell
pn python3-lsprotocol
pn python3-pygls
-- no debconf information
Bug#1066115: mpg123: FTBFS: error: implicit declaration of function ‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]
Hi Andreas, usually I would have implemented your suggestion (and I don't mind anyone implementing it), but I'm not really keen on investing in a dependency that hasn't seen a single upstream release in 12 years and where the last upload was an NMU four years ago from myself dealing with a similar problem. I hope that explains why I took the route of this suboptimal shortcut. Best regards, Joachim
Bug#1067539: 4.11-2.1~exp1 does not fix it
I just ran a pbuilder build of experimental for gap polymaking. The error message persists.
Bug#1067539: Causes FTBFS for gap-polymaking by failing tests 2
Package: polymake Version: 4.11-2 Severity: important Hi. I am seeing FTBFS for my packages gap-polymaking and gap-hapcryst. The error message is > Can't load '/usr/lib/polymake/perlx/5.38.2/x86_64-linux-gnu-thread- multi/auto/Polymake/Ext/Ext.so' for module Polymake::Ext: libflint.so.18: cannot open shared object file: No such file or directory at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 201. This is most likely caused by the latest version of libflint beeing libflint18t64. The bug is similiar to #1053316, just the library is different. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067319 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067296 Sincerely, Joachim
Bug#1066115: mpg123: FTBFS: error: implicit declaration of function ‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]
tag 1066115 + patch thanks Hi, attached is the debdiff for the NMU, uploaded to delayed/10. Similar to the previous NMU it adds -Wno-error=implicit-function-declaration to downgrade these errors back into warnings again. Best regards, Joachimdiff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog --- mpg321-0.3.2/debian/changelog 2020-07-23 17:22:42.0 +0200 +++ mpg321-0.3.2/debian/changelog 2024-03-21 21:39:07.0 +0100 @@ -1,3 +1,11 @@ +mpg321 (0.3.2-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add -Wno-error=implicit-function-declaration to CFLAGS to disable +new defaults from dpkg-buildflags (Closes: #1066115). + + -- Joachim Reichel Thu, 21 Mar 2024 20:39:07 + + mpg321 (0.3.2-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru mpg321-0.3.2/debian/rules mpg321-0.3.2/debian/rules --- mpg321-0.3.2/debian/rules 2020-07-23 17:22:42.0 +0200 +++ mpg321-0.3.2/debian/rules 2024-03-21 21:37:50.0 +0100 @@ -4,7 +4,7 @@ #export DH_VERBOSE=1 -export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -Wno-error=implicit-function-declaration -fcommon +export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -Wno-error=implicit-function-declaration -fcommon MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
Bug#1067197: xserver-xorg-video-nouveau ftbfs
Control: severity -1 normal Am 19.03.2024 um 22:15 schrieb Helge Deller: > Source: xserver-xorg-video-nouveau > Version: 1:1.0.17-3 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: del...@debian.org > > Failure can be seen on hppa architecture, but I assume it will show up on > armel too: I don't think so, it has already been built on armhf. > https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-nouveau=hppa=1%3A1.0.17-3=1710537593=0 > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src > -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 > -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/xorg > -fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri > -I/usr/include/libdrm -I/usr/include/libdrm > -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2 > -Werror=implicit-function-declaration > -ffile-prefix-map=/<>=. -Wformat -Werror=format-security > -Wall -I/usr/include/xorg -fvisibility=hidden -I/usr/include/pixman-1 > -I/usr/include/X11/dri -I/usr/include/libdrm -c ../../src/nv_shadow.c > -fPIC -DPIC -o .libs/nv_shadow.o > ../../src/nv_driver.c: In function ‘NVScreenInit’: > ../../src/nv_driver.c:1451:23: error: implicit declaration of function > ‘wfbScreenInit’; did you mean ‘fbScreenInit’? > [-Werror=implicit-function-declaration] > 1451 | ret = wfbScreenInit(pScreen, FBStart, pScrn->virtualX, > | ^ > | fbScreenInit > cc1: some warnings being treated as errors > make[3]: *** [Makefile:674: nv_driver.lo] Error 1 The problem is that the hppa and powerpc buildds have an outdated version of dpkg-dev installed, although a newer one has been available for over a week. I could and maybe should add dpkg-dev (>= 1.22.6) to Build-Depends, but that is one more thing that needs to be reverted when #1066968 gets fixed. Cheers, Sven
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Tobias. Am Donnerstag, dem 14.03.2024 um 17:20 +0100 schrieb Tobias Frost: > - $2 might be empty, you need to quote it: use "$2" otherwise dpkg will fail That was a stupid one, thanks. Fixed and uploaded. Sincerely, Joachim
Bug#1066968: xserver-xorg-video-nouveau: does not build with -Werror=implicit-function-declaration
Source: xserver-xorg-video-nouveau Version: 1:1.0.17-3 Severity: normal Control: block -1 by 1066966 As a stopgap measure for #1066382, xserver-xorg-nouveau currently disables -Werror=implicit-function-declaration via DEB_BUILD_MAINT_OPTIONS=qa=-bug-implicit-func. This is obviously undesirable and should be reverted if possible. It seems to me that this requires wfbScreenInit to be declared unconditionally in /usr/include/xorg/fb.h, see #1066966.
Bug#1066966: xserver-xorg-dev: wfbScreenInit should be declared unconditionally
Package: xserver-xorg-dev Version: 2:21.1.11-2 Severity: normal Forwarded: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1222 File: /usr/include/xorg/fb.h As noticed in #1066382, xserver-xorg-video-nouveau FTBFS with -Werror=implicit-function-declaration, because wfbScreenInit is not explicitly declared. The file /usr/include/xorg/fb.h has a prototype for it, but currently it is hidden behind #ifdef FB_ACCESS_WRAPPER. Unfortunately, simply #defining FB_ACCESS_WRAPPER in xserver-xorg-video-nouveau does not work because while it makes the package build, Xorg then fails to start with a symbol lookup error. The fix is to declare wfbScreenInit unconditionally, and this is already in the Xserver master branch, but not in the server-21.1-branch. The upstream merge request mentions problems with the autoconf build system which could be fixed by switching to meson. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#1066382: xserver-xorg-video-nouveau: FTBFS: ../../src/nv_driver.c:1451:23: error: implicit declaration of function ‘wfbScreenInit’; did you mean ‘fbScreenInit’? [-Werror=implicit-function-declarat
On 2024-03-13 18:07 +0100, Sven Joachim wrote:
> Control: forwarded -1
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/569
>
> On 2024-03-13 12:47 +0100, Lucas Nussbaum wrote:
>
>> Source: xserver-xorg-video-nouveau
>> Version: 1:1.0.17-2
>> Severity: serious
>> Justification: FTBFS
>> Tags: trixie sid ftbfs
>> User: lu...@debian.org
>> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>>
>> This is most likely caused by a change in dpkg 1.22.6, that enabled
>> -Werror=implicit-function-declaration. For more information, see
>> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
>>
>> Relevant part (hopefully):
>>> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
>>> -I. -I../../src -I.. -Wdate-time -D_FORTIFY_SOURCE=2
>>> -I/usr/include/xorg -fvisibility=hidden -I/usr/include/pixman-1
>>> -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/libdrm
>>> -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2
>>> -Werror=implicit-function-declaration
>>> -ffile-prefix-map=/<>=. -fstack-protector-strong
>>> -fstack-clash-protection -Wformat -Werror=format-security
>>> -fcf-protection -Wall -minline-all-stringops -I/usr/include/xorg
>>> -fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri
>>> -I/usr/include/libdrm -c -o nv04_xv_ovl.lo ../../src/nv04_xv_ovl.c
>>> ../../src/nv_driver.c: In function ‘NVScreenInit’:
>>> ../../src/nv_driver.c:1451:23: error: implicit declaration of
>>> function ‘wfbScreenInit’; did you mean ‘fbScreenInit’?
>>> [-Werror=implicit-function-declaration]
>>> 1451 | ret = wfbScreenInit(pScreen, FBStart,
>>> pScrn->virtualX,
>>> | ^
>>> | fbScreenInit
>
> This has already been reported upstream, unfortunately without a
> followup so far.
Got a reply from Alan Coppersmith, and he mentioned a fix to xorg's fb.h
header file which is in the Xserver master branch, but has not yet been
applied to the server-21.1-branch.
> Adding -DFB_ACCESS_WRAPPER to CPPFLAGS lets the build
> succeed, but I have not tested the resulting binary package yet.
Tested it now, and it does not work at all, xinit fails to start:
,
| /usr/lib/xorg/Xorg: symbol lookup error:
/usr/lib/xorg/modules/drivers/nouveau_drv.so: undefined symbol: wfbPictureInit
`
> See commit d7ba24fb6e4f ("wfb: Fix missing init function decls behind
> FB_ACCESS_WRAPPER") which noticed and fixed the missing function
> declaration, but got reverted in commit ca13913aaf7e.
For a good reason, the commit message mentions the same error which I
got. So I think we should disable -Werror=implicit-function-declaration
in xserver-xorg-video-nouveau for now until there is a fix in the
xorg-server package.
Cheers,
Sven
Bug#1066809: e2fsprogs: dependency loop libss2t64 versus libss2
On 2024-03-13 21:11 +0200, Martin-Éric Racine wrote: > Package: e2fsprogs > Version: 1.47.0-2.4 > Severity: important > > The latest upload introduces a dependency loop between libss2t64 > versus libss2 which also results in the removal of e2fsprogs-l10n. No, there is no dependency loop because libss2 provides libss2t64. Upgrading e2fsprogs resulted in removal of e2fsprogs-l10n because the latter has a rather strict versioned dependency on the former and had not been built yet. Run "apt update", and you should be able to reinstall e2fsprogs-l10n. Cheers, Sven
Bug#1066469: tack: FTBFS: configure: error: No curses header-files found
On 2024-03-13 13:08 +0100, Lucas Nussbaum wrote: > Source: tack > Version: 1.08-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240313 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): >> configure: WARNING: pkg-config is not installed >> checking for specific curses-directory... no >> checking for specified curses library type... curses >> checking for extra include directories... no >> checking if we have identified curses headers... none >> configure: error: No curses header-files found >> tail -v -n \+0 config.log This reminds me that I really should update the tack package to a newer version. The error is still present in tack 1.09 (the latest stable release), but fixed as of tack 1.09-20230201 (the latest development snapshot). @Thomas: since tack 1.09 is more than four years old and there has been no new snapshot for over a year, how about releasing tack 1.10? This bug will likely hit other distros as they upgrade to GCC 14. Cheers, Sven
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/10613 On 2024-02-17 18:53 +0100, Sven Joachim wrote: > Control: severity -1 grave > > On 2024-02-17 13:35 +0100, Lorenzo Beretta wrote: > >> Package: libgl1-mesa-dri >> Version: 24.0.1-1 >> Severity: important >> >> Dear Maintainer, >> >> after the latest upgrade it's impossible for me to run a display manager >> or startx any window manager; after at most a few seconds / keypresses / >> mouse movements the screen freezes, completely unresponsive to anything >> other than the power button; the log below suggests a null pointer. >> >> Running "sleep 30; killall -u lorenzo" as root before startx returns me >> to a tty. >> >> Reverting to the previous version everything works. >> >> I'm running this on a debian derivative, devuan; afaik it shouldn't make >> a difference, as the package is unmodified from debian - I don't know >> how to verify that other than by installing debian in some partition, >> can one start some window manager from a debian chroot/whatever? >> >> If it's ok in debian or you need any more info please do let me know. > > I can reproduce that on my laptop which runs pure Debian, and at least > one other user seems to have the same problem. > >> VGA-compatible devices on PCI bus: >> -- >> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. >> [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 >> OEM] [1002:6611] > > I have the following graphics hardware: > > , > | 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, > | Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] [1002:985\ 0] (rev 40) > ` > > This is also using the radeonsi driver, and the symptoms and the > backtrace are the same as yours. > > Bumping severity to keep this mesa version out of testing, but I will > not be able to investigate the problem because I need the machine and > have already downgraded all packages from src:mesa. There does not seem > to be an upstream report yet. Looks like there is one now and it even has a patch which seems to have been applied in Archlinux and Ubuntu, but not committed upstream. :-( Cheers, Sven
Bug#1066382: xserver-xorg-video-nouveau: FTBFS: ../../src/nv_driver.c:1451:23: error: implicit declaration of function ‘wfbScreenInit’; did you mean ‘fbScreenInit’? [-Werror=implicit-function-declarat
Control: forwarded -1
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/569
On 2024-03-13 12:47 +0100, Lucas Nussbaum wrote:
> Source: xserver-xorg-video-nouveau
> Version: 1:1.0.17-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
>
> Relevant part (hopefully):
>> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
>> -I. -I../../src -I.. -Wdate-time -D_FORTIFY_SOURCE=2
>> -I/usr/include/xorg -fvisibility=hidden -I/usr/include/pixman-1
>> -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/libdrm
>> -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2
>> -Werror=implicit-function-declaration
>> -ffile-prefix-map=/<>=. -fstack-protector-strong
>> -fstack-clash-protection -Wformat -Werror=format-security
>> -fcf-protection -Wall -minline-all-stringops -I/usr/include/xorg
>> -fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri
>> -I/usr/include/libdrm -c -o nv04_xv_ovl.lo ../../src/nv04_xv_ovl.c
>> ../../src/nv_driver.c: In function ‘NVScreenInit’:
>> ../../src/nv_driver.c:1451:23: error: implicit declaration of
>> function ‘wfbScreenInit’; did you mean ‘fbScreenInit’?
>> [-Werror=implicit-function-declaration]
>> 1451 | ret = wfbScreenInit(pScreen, FBStart,
>> pScrn->virtualX,
>> | ^
>> | fbScreenInit
This has already been reported upstream, unfortunately without a
followup so far. Adding -DFB_ACCESS_WRAPPER to CPPFLAGS lets the build
succeed, but I have not tested the resulting binary package yet. See
commit d7ba24fb6e4f ("wfb: Fix missing init function decls behind
FB_ACCESS_WRAPPER") which noticed and fixed the missing function
declaration, but got reverted in commit ca13913aaf7e.
Cheers,
Sven
Bug#1066094: squidguard: Squidguard does not work with default squid apparmor profile
Hello Marco, I think we need an apparmor config file for squidguard. I never have written such a config, but perhaps you have an example of such a config file? Otherwise I need some time for testing to resolve this problem. Have a nice day. Joachim (Germany) pgp2TBPLjodSD.pgp Description: Digitale Signatur von OpenPGP
Bug#1066044: cups: dangling /usr/share/doc/cups*/README.Debian.gz symlinks
Source: cups Version: 2.4.7-1.2 Tags: patch X-Debbugs-Cc: Sven Joachim , Michael Hudson-Doyle Renaming libcups2 to libcups2t64 has caused several README.Debian.gz symlinks to become broken: , | $ symlinks /usr/share/doc/cups* | dangling: /usr/share/doc/cups/README.Debian.gz -> ../libcups2/README.Debian.gz | dangling: /usr/share/doc/cups-core-drivers/README.Debian.gz -> ../libcups2/README.Debian.gz | dangling: /usr/share/doc/cups-client/README.Debian.gz -> ../libcups2/README.Debian.gz | dangling: /usr/share/doc/cups-daemon/README.Debian.gz -> ../libcups2/README.Debian.gz ` They need to be updated and point at ../libcups2t64/README.Debian.gz instead. The following command does the trick: , | $ sed -i 's|^/usr/share/doc/libcups2|/usr/share/doc/libcups2t64|' debian/*.links ` -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#1065634: wv: /usr/share/doc wv is a dangling symlink
Control: tags -1 + patch On 2024-03-07 18:49 +0100, Sven Joachim wrote: > Package: wv > Version: 1.2.9-6.1 > Severity: serious > X-Debbugs-Cc: Sven Joachim , Steve Langasek > > > After renaming the libwv-1.2-4 library package to libwv-1.2-4t64, the > /usr/share/doc/wv symlink has become dangling. > > , > | $ file /usr/share/doc/wv > | /usr/share/doc/wv: broken symbolic link to libwv-1.2-4 > ` > > It should point to libwv-1.2-4t64 instead, obviously. There is a similar broken symlink in the libwv-dev package (which I do not have installed). The attached patch takes care of them. Steve, would you like to upload that? Note that the package is orphaned, therefore I have created a debian/changelog entry for a QA upload rather than for another NMU. Cheers, Sven diff -Nru wv-1.2.9/debian/changelog wv-1.2.9/debian/changelog --- wv-1.2.9/debian/changelog 2024-02-29 06:47:50.0 +0100 +++ wv-1.2.9/debian/changelog 2024-03-07 19:42:29.0 +0100 @@ -1,3 +1,10 @@ +wv (1.2.9-7) unstable; urgency=medium + + * QA upload. + * Fix dangling /usr/share/doc symlinks (Closes: #1065634). + + -- Sven Joachim Thu, 07 Mar 2024 19:42:29 +0100 + wv (1.2.9-6.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru wv-1.2.9/debian/libwv-dev.links wv-1.2.9/debian/libwv-dev.links --- wv-1.2.9/debian/libwv-dev.links 2023-09-17 23:45:41.0 +0200 +++ wv-1.2.9/debian/libwv-dev.links 2024-03-07 19:41:38.0 +0100 @@ -1 +1 @@ -usr/share/doc/libwv-1.2-4 usr/share/doc/libwv-dev +usr/share/doc/libwv-1.2-4t64 usr/share/doc/libwv-dev diff -Nru wv-1.2.9/debian/wv.links wv-1.2.9/debian/wv.links --- wv-1.2.9/debian/wv.links 2023-09-17 23:45:41.0 +0200 +++ wv-1.2.9/debian/wv.links 2024-03-07 19:01:19.0 +0100 @@ -1 +1 @@ -usr/share/doc/libwv-1.2-4 usr/share/doc/wv +usr/share/doc/libwv-1.2-4t64 usr/share/doc/wv
Bug#1065634: wv: /usr/share/doc wv is a dangling symlink
Package: wv Version: 1.2.9-6.1 Severity: serious X-Debbugs-Cc: Sven Joachim , Steve Langasek After renaming the libwv-1.2-4 library package to libwv-1.2-4t64, the /usr/share/doc/wv symlink has become dangling. , | $ file /usr/share/doc/wv | /usr/share/doc/wv: broken symbolic link to libwv-1.2-4 ` It should point to libwv-1.2-4t64 instead, obviously. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.81-nouveau (SMP w/2 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) Versions of packages wv depends on: ii libc62.37-15.1 ii libglib2.0-0t64 2.78.4-3 ii libgsf-1-114 1.14.51-2 ii libwv-1.2-4t64 1.2.9-6.1 wv recommends no packages. Versions of packages wv suggests: ii elinks 0.16.1.1-4.1+b2 ii ghostscript [postscript-viewer] 10.02.1~dfsg-3 ii imagemagick 8:6.9.12.98+dfsg1-5.1+b1 ii imagemagick-6.q16 [imagemagick] 8:6.9.12.98+dfsg1-5.1+b1 ii lynx 2.9.0rel.0-2 ii okular [postscript-viewer] 4:23.08.1-2 ii texlive 2023.20240207-1 -- no debconf information
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -moreinfo Hi Tobias. Thanks for looking into the package. Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > d/source/lintian-overrides > - delete the overrides, seems to be some remnant of earlier packaging. > > d/DEBIAN_RELEASE.txt > - delete this file; the information contained in this files would not >be a process how to create a package for Debian. (and if you need a >file describing certain unusal aspects of the Debian packaging, it >would be README.source (see Debian Policy §4.14) >I recommend checking out git-buildpackage: >https://honk.sigxcpu.org/piki/projects/git-buildpackage/ >https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ >- remove Debian_release.patch -- this is not needed, you work with >your debian/ directory and evolve it, you do not patch it when you >create a new version. > > d/control > - specify Rules-Require-Root > - you manually depend on libsml1. Can you expand why this is needed? > - Build-Depend: s/pkg-config/pkgconf > - remove versions from the versioned build dependencies, if the >debpendency is already fulfilled in oldstable: >- libjson-c-dev, libcurl4-openssl-dev, > > > d/postinst / postrm > - When you create a user, it should start with "_" - see policy 9.2.1 >- Another option might be using systemd's DynamicUser feature to > create the user at runtime. (bonus: some hardening for free.) >- there's systemd-sysuser (works also without systemd as init system) > to use sysusers.d >- do not delete users/groups on package removal. All changes have been done. In addition the repository has been moved to DEP-14 layout. Sincerely, Joachim
Bug#1065483: perl-base: should provide perlapi-5.38.2 on i386
Control: tags -1 + patch
On 2024-03-05 11:47 +0100, Sven Joachim wrote:
> Package: perl-base
> Version: 5.38.2-3.1
> Severity: serious
> X-Debbugs-Cc: Sven Joachim , Steve Langasek
>
>
> On i386, perl-base provides perlapi-5.38.2t64 rather than
> perlapi-5.38.2. This makes tons of packages uninstallable or
> unbuildable and is not what has been agreed upon in #1060246.
There are already 229 packages in state BD-Uninstallable on i386,
on amd64 there are only 19. Personally I have held back packages from
src:e2fsprogs, src:util-linux and src:expat due to multiarch version
skew. This is only going to become worse.
> The reason is a bad check in debian/rules, line 31:
>
> ,
> | # If nonempty, this will determine $Config{debian_abi} and Provides: entries
> | # (otherwise, the Provides: entries will be generated by debian/mkprovides)
> | perlabi =
> | ifeq (,$(filter $(DEB_HOST_GNU_TYPE),i386 hurd-i386))
> | ifeq ($(DEB_HOST_ARCH_BITS),32)
> | perlabi = 5.38.2t64
> | endif
> | endif
> `
>
> Unfortunately DEB_HOST_GNU_TYPE does not match i386 or hurd-i386 on
> these architectures:
>
> ,
> | $ dpkg-architecture -ai386 -qDEB_HOST_GNU_TYPE 2>/dev/null
> | i686-linux-gnu
> | $ dpkg-architecture -ahurd-i386 -qDEB_HOST_GNU_TYPE 2>/dev/null
> | i686-gnu
> `
>
> You may want to filter on DEB_HOST_ARCH instead (make sure it is
> defined).
I have decided to fix the check for DEB_HOST_GNU_TYPE instead. All of
this is going away anyway when perl moves on to version 5.40.
> A quick fix would be appreciated, because reverse dependencies are
> likely going to pick up the wrong perlapi Provides.
There are currently six packages depending on perlapi-5.38.2t64:i386,
but that number is likely going to grow. The second patch adds a
hardcoded dependency not break these reverse dependencies, but it might
be preferable to just request binNMUs for them as long as there are not
too many.
Cheers,
Sven
From 016030f4f7d4d3317016c3f9af3981030dfef913 Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Wed, 6 Mar 2024 09:53:06 +0100
Subject: [PATCH] Fix perlapi Provides for i386 and hurd-i386
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index a5a3565..43f923e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
# If nonempty, this will determine $Config{debian_abi} and Provides: entries
# (otherwise, the Provides: entries will be generated by debian/mkprovides)
perlabi =
-ifeq (,$(filter $(DEB_HOST_GNU_TYPE),i386 hurd-i386))
+ifeq (,$(filter $(DEB_HOST_GNU_TYPE),i686-linux-gnu i686-gnu))
ifeq ($(DEB_HOST_ARCH_BITS),32)
perlabi = 5.38.2t64
endif
--
2.43.0
From 8509b7145c29e936e4b76b83f31fbc1d397d69dc Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Wed, 6 Mar 2024 10:02:43 +0100
Subject: [PATCH] Temporarily provide perlapi-5.38.2t64 on i386 and hurd-i386
There are already a few packages which have picked up the new
dependency, provide perlapi-5.38.2t64 not to break them.
---
debian/control | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/control b/debian/control
index acc8e5a..222ae6c 100644
--- a/debian/control
+++ b/debian/control
@@ -81,6 +81,7 @@ Provides: ${perlapi:Provides},
libfile-temp-perl (= 0.2311),
libfile-path-perl (= 2.18),
libio-socket-ip-perl (= 0.41),
+ perlapi-5.38.2t64 [i386 hurd-i386],
Suggests: perl, sensible-utils
Description: minimal Perl system
Perl is a scripting language used in many system scripts and utilities.
--
2.43.0
Bug#1065483: perl-base: should provide perlapi-5.38.2 on i386
Package: perl-base
Version: 5.38.2-3.1
Severity: serious
X-Debbugs-Cc: Sven Joachim , Steve Langasek
On i386, perl-base provides perlapi-5.38.2t64 rather than
perlapi-5.38.2. This makes tons of packages uninstallable or
unbuildable and is not what has been agreed upon in #1060246.
The reason is a bad check in debian/rules, line 31:
,
| # If nonempty, this will determine $Config{debian_abi} and Provides: entries
| # (otherwise, the Provides: entries will be generated by debian/mkprovides)
| perlabi =
| ifeq (,$(filter $(DEB_HOST_GNU_TYPE),i386 hurd-i386))
| ifeq ($(DEB_HOST_ARCH_BITS),32)
| perlabi = 5.38.2t64
| endif
| endif
`
Unfortunately DEB_HOST_GNU_TYPE does not match i386 or hurd-i386 on
these architectures:
,
| $ dpkg-architecture -ai386 -qDEB_HOST_GNU_TYPE 2>/dev/null
| i686-linux-gnu
| $ dpkg-architecture -ahurd-i386 -qDEB_HOST_GNU_TYPE 2>/dev/null
| i686-gnu
`
You may want to filter on DEB_HOST_ARCH instead (make sure it is
defined). A quick fix would be appreciated, because reverse
dependencies are likely going to pick up the wrong perlapi Provides.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
On 2024-03-04 16:01 +0100, Axel Beckert wrote:
> Source: aptitude
> Version: 0.8.13-5
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: a...@debian.org, z...@debian.org
>
> Citing from https://buildd.debian.org/status/package.php?p=aptitude:
>
> BinNMU changelog for aptitude on amd64, arm64, armel, armhf, i386,
> mips64el, ppc64el, riscv64, s390x, alpha, hppa, hurd-i386, ia64,
> loong64, m68k, powerpc, ppc64, sh4, sparc64 and x32:
>
> Rebuild for time_t
>
> Tail of log for aptitude on armel:
>
> /usr/include/cppunit/TestAssert.h:161:6: note: candidate:
> ‘template void CppUnit::assertEquals(const T&, const T&,
> SourceLine, const std::string&)’
> 161 | void assertEquals( const T& expected,
> | ^~~~
> /usr/include/cppunit/TestAssert.h:161:6: note: template argument
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note: deduced conflicting types for
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long
> int’})
> 187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
> | ^
> make[3]: *** [Makefile:869: test_misc.o] Error 1
> make[3]: Leaving directory '/<>/build/tests'
> make[2]: *** [Makefile:1169: check-am] Error 2
> make[2]: Leaving directory '/<>/build/tests'
> /bin/sh: 1: ./cppunit_test: not found
> make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:22: binary-arch] Error 2
>
> Tail of log for aptitude on armhf:
>
> /usr/include/cppunit/TestAssert.h:161:6: note: candidate:
> ‘template void CppUnit::assertEquals(const T&, const T&,
> SourceLine, const std::string&)’
> 161 | void assertEquals( const T& expected,
> | ^~~~
> /usr/include/cppunit/TestAssert.h:161:6: note: template argument
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note: deduced conflicting types for
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long
> int’})
> 187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
> | ^
> make[3]: *** [Makefile:869: test_misc.o] Error 1
> make[3]: Leaving directory '/<>/build/tests'
> make[2]: *** [Makefile:1169: check-am] Error 2
> make[2]: Leaving directory '/<>/build/tests'
> /bin/sh: 1: ./cppunit_test: not found
> make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:22: binary-arch] Error 2
>
> Given the time and the architectures failing, this is probably related
> to dpkg switching on -Werror=implicit-function-declaration on these
> architectures (see https://bugs.debian.org/1065371 and a good summary
> of a similar case in https://bugs.debian.org/1065431 against lintian).
Not really, these arches now default to a 64-bit time_t and therefore
you get the conflicting types (suseconds_t is a long int,
__suseconds64_t a long long int). This has nothing to do with implicit
function declarations.
Cheers,
Sven
Bug#643560: Personal groups should result in umask 002 by default
On 2011-09-27 09:36 -0700, Steve Langasek wrote: > tags 643560 confirmed > thanks > > On Tue, Sep 27, 2011 at 03:27:47PM +0100, Ian Jackson wrote: >> Personal groups are the default on Debian. The purpose of personal >> groups is to allow users to run with a umask of 002 so that they can >> sensibly access shared filespace areas whose access is controlled by >> group. > >> This only works if the default umask is actually 002. This should >> probably now be achieved by enabling the pam_umask module with the >> "usergroups" option in some appropriate config file. > > Yes, this is planned for wheezy. I consider upstreaming of the patch in bug > #583958 (and then pulling it into Debian) a prerequisite. In pam 1.5.3-1, both #583958 and #711104 have been fixed, and I found out (much to my surprise, actually) that the umask after login had changed from 022 to 002. So it seems this bug should be closed, too. Cheers, Sven
Bug#1065242: libuuid1: removing libuuid1t64 leads to file losses
Package: libuuid1 Version: 2.39.3-7 Severity: serious The last upload renamed libuuid1t64 back to libuuid1, but because the former has an unversioned Replaces: on the latter, it will not take the library files back. Removing the libuuid1t64 package will therefore silently lose the files. It seems to me that libuuid1 needs a Replaces/Conflicts on libuuid1t64 to prevent this scenario. Additionally, in order not to break reverse dependencies of libuuid1t64, the Provides: libuuid1t64 needs to be versioned. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#1065121: xdelta: still depends on libxdelta2
Control: tags -1 + patch On 2024-02-29 23:26 +0100, Sven Joachim wrote: > Package: xdelta > Version: 1.1.3-10.5 > Severity: serious > X-Debbugs-Cc: Sven Joachim , Steve Langasek > > > The xdelta package still depends on libxdelta2, rather than on > libxdelta2t64 as it should. > > The build log on m68k[1] shows that on this architecture libxdelta2t64 > gained a dependency on libxdelta2 as well. Builds for other 32-bit > architectures are still missing, but I suspect the libxdelta2t64 package > will not installable on architectures where it does not provide > libxdelta2. > > Removing the debian/shlibs.local file is most certainly going to fix > this mess, but I have not tested it. Did a test rebuild on amd64 now with the offending shlibs.local file removed, and the result looks correct. This file had been redundant for many years already, since it was identical to debian/libxdelta2.shlibs. Trivial patch attached in case someone wants to upload another NMU. Cheers, Sven diff -Nru xdelta-1.1.3/debian/changelog xdelta-1.1.3/debian/changelog --- xdelta-1.1.3/debian/changelog 2024-02-29 07:20:41.0 +0100 +++ xdelta-1.1.3/debian/changelog 2024-03-01 16:25:51.0 +0100 @@ -1,3 +1,10 @@ +xdelta (1.1.3-10.6) unstable; urgency=medium + + * Non-maintainer upload. + * Remove debian/shlibs.local (Closes: #1065121). + + -- Sven Joachim Fri, 01 Mar 2024 16:25:51 +0100 + xdelta (1.1.3-10.5) unstable; urgency=medium * Non-maintainer upload. diff -Nru xdelta-1.1.3/debian/shlibs.local xdelta-1.1.3/debian/shlibs.local --- xdelta-1.1.3/debian/shlibs.local 2021-12-31 17:50:22.0 +0100 +++ xdelta-1.1.3/debian/shlibs.local 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ -libxdelta 2 libxdelta2 (>= 1.1.3) -libedsio 0 libxdelta2 (>= 1.1.3)
Bug#1065121: xdelta: still depends on libxdelta2
Package: xdelta Version: 1.1.3-10.5 Severity: serious X-Debbugs-Cc: Sven Joachim , Steve Langasek The xdelta package still depends on libxdelta2, rather than on libxdelta2t64 as it should. The build log on m68k[1] shows that on this architecture libxdelta2t64 gained a dependency on libxdelta2 as well. Builds for other 32-bit architectures are still missing, but I suspect the libxdelta2t64 package will not installable on architectures where it does not provide libxdelta2. Removing the debian/shlibs.local file is most certainly going to fix this mess, but I have not tested it. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 1. https://buildd.debian.org/status/fetch.php?pkg=xdelta=m68k=1.1.3-10.5=1709209632=0
Bug#1064969: apt: can't upgrade with aptitude
Control: severity -1 normal
On 2024-02-28 15:49 +0100, Vincent Lefevre wrote:
> Source: apt
> Version: 2.7.12+nmu1
> Severity: serious
>
> While there are no upgrade issues with apt itself (according
> to "apt install -s apt"), aptitude does not want to upgrade
> apt automatically, while this just appears to be a package
> rename:
>
> # aptitude install apt
> The following packages will be upgraded:
> apt{b} apt-doc
> 2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
> Need to get 1622 kB of archives. After unpacking 0 B will be used.
> The following packages have unmet dependencies:
> apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be
> installed
> apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
> The following actions will resolve these dependencies:
>
> Keep the following packages at their current version:
> 1) apt [2.7.12 (now, testing)]
>
> I don't know whether this is actually an issue with aptitude, but at
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059068#15
>
> David Kalnischkies says:
> | You should really know this by now as that isn't your first report, but
> | okay: Upgrade problems are NEVER a problem to be solved in apt,
> | they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
>
> So, I suppose that this is also the case for aptitude: if aptitude
> cannot upgrade just because of a rename, then this is a problem in
> the involved packages.
No, in this case it is a problem with aptitude's resolver which
manifests itself due to the following configuration setting:
> Aptitude::ProblemResolver::SolutionCost "safety, removals";
This does cause aptitude to hold apt back by default, rather than remove
libapt-pkg6.0. You can press 'n' at the prompt, the next solution
aptitude then suggests is to upgrade apt.
Cheers,
Sven
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi. Thanks for taking the time to review my package. Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > d/postinst / postrm > - When you create a user, it should start with "_" - see policy > 9.2.1 This has been implemented and is on its way, see https://github.com/volkszaehler/vzlogger/pull/628 It was a bit complicated because I need to rename an existing user. There are installations of the existing native package. I am therefore unsure if it is good to do this. Going by the letter which is "When maintainers choose a new hardcoded or dynamically generated username" the username has already been choosen when the debian/vzlogger.init script was created. Since it is a now or never situation and since the number of existing installations is still low I tend to rename the user. Any opinions are appreciated. Sincerely, Joachim
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi. I'll reply to the DEP-14 issue while working on the others. Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > https://github.com/volkszaehler/vzlogger.git > > > > on branch debian-0.8.3-1. > > (There is no such branch on that repo, but a "debian" one.) Sorry, forgot to merge that. > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for > recommendation how to layout the repository used for packaging, I'd > even recommend to use an extra repository for the packaging. I know about DEP-14 and actually tried it. I found it however very inconvenient to use and I think this is because it is inappropriate for the current situation. The package is maintained in the upstream repository as a native package (by me). This is necessary because Debian packages are built as part of the upstream releases. So all packaging changes happen upstream first. The changes that are later needed to turn an upstream native release into a Debian release are few and won't change much over time. So a patch makes sense IMHO. This situation can change when vzlogger reaches stable (and as a result reaches Raspbian). At that point maintaining a package in the upstream repo is no longer necessary. For now I would prefer to use the suggested release workflow (which I am already using for libsml, where the situation is the same). I am aware that the DEP-14 layout works well if upstream is not doing package maintenance and I am not generally against it. My other current ITP #1062335 is using it. https://salsa.debian.org/debian-iot-team/tasmota-device-manager Sincerely, Joachim
Bug#1064343: tput sgr0 adds uncalled-for codes
I would like to add a few more points here, not to prolong the discussion but rather for future reference and for myself. On 2024-02-21 07:06 +0100, Adam Borowski wrote: > On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote: >> The reason for including \E(B here is that sgr0 should cancel the >> effects of a previous smacs (start alternate character set) sequence and >> thus includes the rmacs (end alternate character set) escape sequence. This has been the case from the early days of ncurses when ESR started to maintain the terminfo collection. On archive.debian.org I found a version on ncurses 1.9.4 with the terminfo.src file version 9.8[1]. The ncurses manpages do not seem to explicitly mention this detail, but implicitly it appears a few times, for instance in termcap(3ncurses): , | termcap has nothing analogous to terminfo's set_attributes (sgr) | capability. One consequence is that termcap applications assume that | “me” (equivalent to terminfo's exit_attribute_mode (sgr0) capability) | does not reset the alternate character set. ncurses checks for, and | modifies the data shared with, the termcap interface to accommodate the | latter's limitation in this respect. ` > Then it combines two completely different concepts in one label. SGR is > for character attributes, G0/G1 are for encoding. You might think of it that way, but in (n)curses A_ALTCHARSET is just another video attribute, the concepts are not that different. >> Closing the bug, because everything works as intended. > > Well, I'm not going to fight a BTS war, but I don't agree with your > decision. If you want to see changes, please propose them upstream. If Thomas follows your reasoning, great for you. Otherwise nothing is ever going to happen anyway, because there is no way I am going to deviate from upstream here (and patch sgr0 in a gazillion terminfo entries). Cheers, Sven 1. https://archive.debian.org/debian/dists/Debian-0.93R6/source/devel/ncurses-1.9.4-0.tar.gz
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "vzlogger": * Package name : vzlogger Version : 3.1-4 Upstream contact : Joachim Zobel * URL : http://wiki.volkszaehler.org/software/controller/vzlogger * License : GPL-3 * Vcs : https://github.com/volkszaehler/vzlogger Section : net The source builds the following binary packages: vzlogger - program to read measurements from smart meters and log them to Influxdb or forward them via MQTT. vzlogger is a tool to read and log measurements of a wide variety of smart meters and sensors. It supports various commonly used protocols such as s0, d0, sml, oms and others. It can write these data to an Influxdb, forward them via MQTT, make them available via HTTP or eport them to a volkszaehler.org middleware. The package is maintained in the upstream repository. Upstream (which I am part of) currently builds native packages. These are patched (a switch from native to quilt, a different changelog and a version >= 3.0 for the dependency on openssl) to make them more suitable for debian. The package is therefore availabe in the upstream repo https://github.com/volkszaehler/vzlogger.git on branch debian-0.8.3-1. Alternatively, you can download the package with 'dget' using this command: dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc Regards, -- Joachim Zobel
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
Control: severity -1 grave On 2024-02-17 13:35 +0100, Lorenzo Beretta wrote: > Package: libgl1-mesa-dri > Version: 24.0.1-1 > Severity: important > > Dear Maintainer, > > after the latest upgrade it's impossible for me to run a display manager > or startx any window manager; after at most a few seconds / keypresses / > mouse movements the screen freezes, completely unresponsive to anything > other than the power button; the log below suggests a null pointer. > > Running "sleep 30; killall -u lorenzo" as root before startx returns me > to a tty. > > Reverting to the previous version everything works. > > I'm running this on a debian derivative, devuan; afaik it shouldn't make > a difference, as the package is unmodified from debian - I don't know > how to verify that other than by installing debian in some partition, > can one start some window manager from a debian chroot/whatever? > > If it's ok in debian or you need any more info please do let me know. I can reproduce that on my laptop which runs pure Debian, and at least one other user seems to have the same problem. > VGA-compatible devices on PCI bus: > -- > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 > OEM] [1002:6611] I have the following graphics hardware: , | 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, | Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] [1002:985\ 0] (rev 40) ` This is also using the radeonsi driver, and the symptoms and the backtrace are the same as yours. Bumping severity to keep this mesa version out of testing, but I will not be able to investigate the problem because I need the machine and have already downgraded all packages from src:mesa. There does not seem to be an upstream report yet. Cheers, Sven
Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done
On 2024-02-11 22:10 +0100, Rene Engelhard wrote: > Source: gpgme1.0 > Version: 1.18.0-4.1~exp1 > Severity: important > > [ let's no get into a discussion on the sense of this transition. I > actually believe this isn't needed and we can leave 32 bit die in 2038 > but anyways... > > The transition is ongoing now in experimental. So be it ] > > > Hi, > > > I just tried a rebuild of libreoffice with > DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens. > > It failed in a certificate unit tests so I tried to rebuild the > "certificate" related (build-)dependencies also with > DEB_HOST_MAINT_OPTIONS="abi=+time64" The correct variable is DEB_BUILD_MAINT_OPTIONS, as you have already noticed. > While doing so I noticed that gpgme1.0 doesn't define -D_TIME_BITS=64 > even when built for t64 (as in the experimental NMU renaming to t64) > on the affected architectures (anything 32-bit except i386). > > This is probably because it doesn't honout dpkg-buildflags. No, this is because debian/rules already sets DEB_BUILD_MAINT_OPTIONS, overriding the value from the environment. Either add abi=+time64 there or set DEB_BUILD_OPTIONS rather than DEB_BUILD_MAINT_OPTIONS in the environment. I don't think there is a bug here. Cheers, Sven
Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'
Package: console-setup
Version: 1.225
Severity: grave
After the upgrade from 1.223, console-setup.service failed to start due
to a syntax error in the setupcon script:
,
| $ setupcon
| /usr/bin/setupcon: 1386: Syntax error: Missing '))'
`
It looks like dash does not like the construct in line 907 where there
is an opening '$((' but the closing parentheses are split.
,
| $ dash << 'EOF'
| > echo $((true))
| > echo $((true) )
| > EOF
| 0
| dash: 3: Syntax error: Missing '))'
| $
`
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Bug#1063402: libnuma1: get_mempolicy: Function not implemented
Package: libnuma1 Version: 2.0.17-2 Severity: normal Forwarded: https://github.com/numactl/numactl/issues/212 Tags: fixed-upstream After today's upgrade I noticed the error message get_mempolicy: Function not implemented appearing on my terminal and wondered where it comes from. It turns out that various procps programs dlopen() libnuma.so.1, and libnuma prints this message on stderr if NUMA support is not available in the kernel (CONFIG_NUMA is unset in my self-built kernel). There are many scripts which run ps(1), so this message can pop up quite often. For details see https://github.com/numactl/numactl/issues/212 which upstream claims has been fixed in numactl 2.0.18, so an upgrade to that version would be appreciated. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.77-nouveau (SMP w/2 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) Versions of packages libnuma1 depends on: ii libc6 2.37-15 libnuma1 recommends no packages. libnuma1 suggests no packages. -- no debconf information
Bug#1063062: vte: NMU diff for 64-bit time_t transition
On 2024-02-04 19:50 +, Steve Langasek wrote:
> Source: vte
> Version: 1:0.28.2-6
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> diff -Nru vte-0.28.2/debian/control vte-0.28.2/debian/control
> --- vte-0.28.2/debian/control 2019-02-02 12:52:36.0 +
> +++ vte-0.28.2/debian/control 2024-02-04 19:24:45.0 +
> @@ -76,7 +79,7 @@
> Package: libvte-common
> Architecture: all
> Depends: ${misc:Depends}
> -Breaks: libvte9 (<< 1:0.28)
> +Breaks: libvte9t64 (<< 1:0.28)
This change (and the corresponding one in control.in) looks incorrect to
me. Old versions of the library package (in this case versions before
1:0.28) are not going to be renamed retroactively, so the Breaks should
be left alone.
Bug in your conversion script?
Cheers,
Sven
Bug#1062246: libcdk5: NMU diff for 64-bit time_t transition
On 2024-01-31 20:15 +, Steve Langasek wrote:
> Source: libcdk5
> Version: 5.0.20180306-3
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> Dear maintainer,
Not the maintainer here, I think he is rather inactive these days.
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> libcdk5 as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time. Therefore I have prepared a 0-day NMU for libcdk5
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
As you likely have noticed, an upload to experimental was not possible
because a newer version is already there. What is the backup plan?
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.
This package already has an ABI tag from a previous transition[1], and I
think it would be better to replace it rather than add another one on
top of it, i.e. rename the library package to libcdk5t64 rather than
libcdknc6t64. See the attached patch (against the original version in
unstable), I have tested that it builds and that libcdk5t64 correctly
Provides: libcdk5nc6 (= 5.0.20180306-3.1).
> diff -Nru libcdk5-5.0.20180306/debian/libcdk5nc6t64.lintian-overrides
> libcdk5-5.0.20180306/debian/libcdk5nc6t64.lintian-overrides
> --- libcdk5-5.0.20180306/debian/libcdk5nc6t64.lintian-overrides
> 1970-01-01 00:00:00.0 +
> +++ libcdk5-5.0.20180306/debian/libcdk5nc6t64.lintian-overrides
> 2024-01-31 20:15:03.0 +
> @@ -0,0 +1,2 @@
> +libcdk5nc6t64: package-name-doesnt-match-sonames libcdk5
> +libcdk5nc6t64: package-name-doesnt-match-sonames libcdk5nc6
This adds another override rather than replacing the current one. My
patch fixes that as well.
Cheers,
Sven
1. https://bugs.debian.org/892280
diff -Nru libcdk5-5.0.20180306/debian/changelog libcdk5-5.0.20180306/debian/changelog
--- libcdk5-5.0.20180306/debian/changelog 2018-07-08 14:01:56.0 +0200
+++ libcdk5-5.0.20180306/debian/changelog 2024-01-31 21:15:03.0 +0100
@@ -1,3 +1,10 @@
+libcdk5 (5.0.20180306-3.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek Wed, 31 Jan 2024 20:15:03 +
+
libcdk5 (5.0.20180306-3) unstable; urgency=medium
* debian/tests/control:
diff -Nru libcdk5-5.0.20180306/debian/control libcdk5-5.0.20180306/debian/control
--- libcdk5-5.0.20180306/debian/control 2018-07-08 13:42:11.0 +0200
+++ libcdk5-5.0.20180306/debian/control 2024-01-31 21:15:03.0 +0100
@@ -8,12 +8,15 @@
Vcs-Git: https://salsa.debian.org/debian/libcdk5.git
Vcs-Browser: https://salsa.debian.org/debian/libcdk5
-Package: libcdk5nc6
+Package: libcdk5t64
+Provides: ${t64:Provides}
+Breaks: libcdk5nc6 (<< ${source:Version})
Architecture: any
Multi-Arch: same
Depends: ${misc:Depends}, ${shlibs:Depends}
Conflicts: libcdk5
-Replaces: libcdk5
+Replaces: libcdk5nc6, libcdk5
+X-Time64-Compat: libcdk5nc6
Description: C-based curses widget library
CDK stands for "Curses Development Kit". CDK sits on top of the curses
library and provides 22 ready to use widgets for rapid application
@@ -24,7 +27,7 @@
Package: libcdk5-dev
Architecture: any
Section: libdevel
-Depends: libcdk5nc6 (= ${binary:Version}), libncurses-dev, ${misc:Depends}
+Depends: libcdk5t64 (= ${binary:Version}), libncurses-dev, ${misc:Depends}
Description: C-based curses widget library (development files)
CDK stands for "Curses Development Kit". CDK sits on top of the curses
library and provides 22 ready to use widgets for rapid application
diff -Nru libcdk5-5.0.20180306/debian/libcdk5nc6.install libcdk5-5.0.20180306/debian/libcdk5nc6.install
--- libcdk5-5.0.20180306/debian/libcdk5nc6.install 2018-07-08 13:42:11.0 +0200
+++ libcdk5-5.0.20180306/debian/libcdk5nc6.install 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru libcdk5-5.0.20180306/debian/libcdk5nc6.lintian-overrides libcdk5-5.0.20180306/debian/libcdk5nc6.lintian-overrides
---
Bug#1062470: directfb: FTBFS: debian/libdirectfb-1.7-7t64.install is not executable
Source: directfb Version: 1.7.7-11.1~exp1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Sven Joachim , Michael Hudson-Doyle , Steve Langasek The experimental upload of directfb FTBFS on all architectures[1], because debian/libdirectfb-1.7-7t64.install is supposed to be run by dh-exec, but is lacking the executable bits. I am not well informed enough about the 64-bit time_t transition to judge if this is a systematic error in whatever tool that converted the source package or just a mistake in this particular upload. The debian/libdirectfb-1.7-7.install file in unstable has its executable bits set. 1. https://buildd.debian.org/status/package.php?p=directfb=experimental
Bug#1062406: debian-ports-archive-keyring: obsolete conffile left behind
Package: debian-ports-archive-keyring Version: 2024.01.31 Severity: normal Upgrading from 2024.01.05 left the obsolete conffile /etc/apt/trusted.gpg.d/debian-ports-archive-2023.gpg on my system, because debian/debian-ports-archive-keyring.maintscript has not been updated when the 2023 key was moved to the removed keyring. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#1062335: ITP: tasmota-device-manager -- GUI application to manage, configure and monitor devices flashed with Tasmota firmware
Package: wnpp Severity: wishlist Owner: Joachim Zobel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tasmota-device-manager Version : 0.2.13 Upstream Contact: Jacek Ziółkowski> * URL : https://github.com/jziolkowski/tdm * License : GPL-3 Programming Lang: Python Description : GUI application to manage, configure and monitor devices flashed with Tasmota firmware The Tasmota device manager provides one monitoring and management interface for all Tasmota devices. It features - a clean, readable interface - autodetection of devices following the default topic template for Tasmota and for HomeAssistant Auto Discovery protocol - module and GPIO configuration - rules editor - devices with different syntax can be added manually - clean retained MQTT topic messages - toggleable active querying of telemetry - passive monitoring of state and telemetry - relay control via context menu on device list - MQTT console with payload preview, sorting and filtering - selectable detail columns in device list - BSSID aliasing for larger deployments Having one GUI to manage all Tasmota devices in a home environment is a major improvement over having to access them individually through their web interfaces. I would like to maintain this package with the Debian-iot-maintainers.
Bug#1059783: libncursesw6: wmouse_trafo doesn't appear to always reject out-of-bounds positions
On 2024-01-01 05:14 +0100, наб wrote: > Package: libncursesw6 > Version: 6.4+20231121-1 > Severity: normal > > Dear Maintainer, > > I am attaching a repro.c program that when built with > cc -O3 -g -Wall -Wextra -DNCURSES_WIDECHAR -D_GNU_SOURCE repro.c > -lncursesw -ltinfo -o repro You might just as well have said that you are hacking on the urlview package… > presents a UI in the form of > first line > -> L1 > L2 > L3 > L4 > L5 > last line > > Mousing is enabled, and if you click on a line the cursor on the left > moves to select it. > > The first line and last line are on stdscr, the rest of the screen is > urlswin = newpad(LINES, COLS), rendered via > pnoutrefresh(urlswin, /**/ url[first_on_page].cursor_y + fudge, 0, /**/ 1 > /*title line*/, 0, LINES - 2, COLS); > > On KEY_MOUSE and BUTTON1_CLICKED: > getmouse(); > if(!wmouse_trafo(urlswin, , , false)) > break; > and the line targeted is found and selected. > > Clicking on first line correctly hits the break. > Clicking on last line incorrectly continues on. > > This shows as scrolling to the next screen > (since the line selected is L6, which would be under last line). > > This /only happens/ if the lines go all the way to the line above last. > If you click on any line below a non-full screen (s/1000/10/ or scroll down), > nothing happens. > Is this a weird thing with the edge of the screen? > Or with how pnoutrefresh accounts for the undrawn parts of the pad? Neither. It's that the urlswin pad is larger than what fits on the screen, and the wmouse_trafo() function is not designed to work with that. If you look at its source[1], you can see that it calls wenclose() to decide if the mouse event happened inside the window, and the latter simply looks at the window coordinates[2]. If you insist on using a pad larger than the screen size, you will have to work around that limitation somehow, I am afraid. For instance, after calling getmouse(), check if ev.y is in the area that you allocated on the screen for the visible parts of urlswin. Cheers, Sven 1. https://sources.debian.org/src/ncurses/6.4%2B20240113-1/ncurses/base/lib_mouse.c/#L2051 2. https://sources.debian.org/src/ncurses/6.4%2B20240113-1/ncurses/base/lib_mouse.c/#L1993
Bug#1061610: debhelper: cp --update=none requires coreutils 9.3 or newer
On 2024-01-27 13:46 +0100, Sven Joachim wrote:
> Package: libdebhelper-perl
> Version: 13.12
> Severity: important
> X-Debbugs-Cc: Sven Joachim , debian-h...@lists.debian.org
>
> Commit 018a0c9a7164f ("Dh_Lib.pm: Fix warning from `cp -n`") uses cp's
> --update=none option which has been introduced rather recently, namely
> in coreutils 9.3. Older versions of cp do not understand this option,
> complain and refuse to operate. For instance dh_update_autotools_config
> fails with older coreutils:
>
> ,
> | $ cp --version | head -n1
> | cp (GNU coreutils) 9.1
> | $ dh_update_autotools_config
> | cp: option '--update' doesn't allow an argument
> | Try 'cp --help' for more information.
> | dh_update_autotools_config: error: cp -a --update=none
> | --reflink=auto config.guess
> |
> debian/.debhelper/bucket/files/ec2577614252326f889df1de97b9a457c03a9a94811048563c211a44496d8ba3.tmp
> | returned exit code 1
> `
>
> This is obviously bad for backports, more urgently it is going to make
> many packages FTBFS on hurd-i386 which is stuck at coreutils 9.1-1.
>
> I will open a separate bug on coreutils for giving the questionable
> advice to use the --update=none option.
Reported as #1061612.
Cheers,
Sven
Bug#1061612: coreutils: cp -n deprecation warning gives questionable advice
Package: coreutils Version: 9.4-3+b1 , | $ cp -n /bin/true tmp | cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead ` The advice to use the --update=none option is highly questionable, because this option is even less portable than -n. It is not available in coreutils older than 9.3 or in other cp implementations. The result is that package maintainers follow the deprecation advice likely without also introducing a versioned dependency on coreutils, causing problems for backports and partial upgrades. There is also one Debian port (hurd-i386) which does not even have a recent enough coreutils version. See 1061610 in debhelper, which I have just opened.
Bug#1061610: debhelper: cp --update=none requires coreutils 9.3 or newer
Package: libdebhelper-perl
Version: 13.12
Severity: important
X-Debbugs-Cc: Sven Joachim , debian-h...@lists.debian.org
Commit 018a0c9a7164f ("Dh_Lib.pm: Fix warning from `cp -n`") uses cp's
--update=none option which has been introduced rather recently, namely
in coreutils 9.3. Older versions of cp do not understand this option,
complain and refuse to operate. For instance dh_update_autotools_config
fails with older coreutils:
,
| $ cp --version | head -n1
| cp (GNU coreutils) 9.1
| $ dh_update_autotools_config
| cp: option '--update' doesn't allow an argument
| Try 'cp --help' for more information.
| dh_update_autotools_config: error: cp -a --update=none --reflink=auto
config.guess
debian/.debhelper/bucket/files/ec2577614252326f889df1de97b9a457c03a9a94811048563c211a44496d8ba3.tmp
returned exit code 1
`
This is obviously bad for backports, more urgently it is going to make
many packages FTBFS on hurd-i386 which is stuck at coreutils 9.1-1.
I will open a separate bug on coreutils for giving the questionable
advice to use the --update=none option.
Bug#1059760: postfix: installs postfix-instance-generator into /lib
Control: found -1 3.8.5-1 On 2023-12-31 15:31 +0100, Chris Hofstaedtler wrote: > Source: postfix > Version: 3.8.4-1 > User: helm...@debian.org > Usertag: dep17m2 > > Hi, > > postfix installs postfix-instance-generator into > /lib/systemd/system-generators. This appears to be a hard-coded > path. > > For the currently ongoing Debian UsrMerge effort [1], this file > should move below /usr. > > If you wanted to, you could ask systemd.pc for the correct path: > pkg-config --variable=systemdsystemgeneratordir systemd > > Please make sure this gets fixed well before trixie's transition > freeze. > Please also read the linked wiki page about uploading to > experimental, so dumat can check your package (also explained > there). While all regular files have been moved below /usr/lib/systemd in version 3.8.5-1, postfix still ships the /lib/systemd/system-generators directory. Removing the last line from debian/postfix.dirs should fix that, see the attached (trivial, but untested) patch. Cheers, Sven diff --git a/debian/postfix.dirs b/debian/postfix.dirs index f9e42cc3..253d301b 100644 --- a/debian/postfix.dirs +++ b/debian/postfix.dirs @@ -34,4 +34,3 @@ var/spool/postfix/usr/lib/zoneinfo var/spool/postfix/usr/lib/sasl2 var/log var/lib/postfix -lib/systemd/system-generators
Bug#1061152: asymptote: autopkgtest should test installed package
Hi Hilmar, Am 24.01.2024 um 12:42 schrieb Preuße, Hilmar: > On 19.01.2024 17:23, Sven Joachim wrote: > > Hello, > >> Your package's autopkgtest runs the upstream test suite which is >> nice. However, it first builds the program and then tests that, >> rather than the package from the archive. This is not very useful, >> as changes in reverse dependencies could cause breakage at runtime >> which might vanish after a rebuild. >> > > Not sure how to change that. I removed the "build-needed" restriction > from the test suite control file and run the autopkgtest as follows: > > autopkgtest asymptote_2.86+ds1-2_amd64.deb asymptote_2.86+ds1-2.dsc -- > schroot unstable-amd64-sbuild > > The test fails: > > (Reading database ... 52447 files and directories currently installed.) > Removing autopkgtest-satdep (0) ... > autopkgtest [12:35:24]: test test-suite: [--- > make: *** No rule to make target 'test'. Stop. > autopkgtest [12:35:25]: test test-suite: ---] > autopkgtest [12:35:25]: test test-suite: - - - - - - - - - - results > - - - - - - - - - - > test-suite FAIL non-zero exit status 2 > autopkgtest [12:35:25]: summary > test-suite FAIL non-zero exit status 2 > > ...probably b/c the build did not run yet and there is no Makefile. Yes, the Makefile is generated from Makefile.in. > Were you able to run the test suite w/o running a build first? If yes > let me know how. Thanks! I have not tried it, but in the tests/ directory there is a nice Makefile which can be used. It only needs to be persuaded to run the installed asy program rather than the one from the parent directory. Something like the attached patch might work, at least if run the test-suite script under autopkgtest (otherwise you need to create the $AUTOPKGTEST_TMP temporary directory first). Sorry for not having tested the patch - actually I do not use asymptote, only its strange autopkgtest failures like [1] last week motivated me to look at it. Good luck, Sven 1. https://ci.debian.net/packages/a/asymptote/testing/amd64/41886606/ diff --git a/debian/tests/test-suite b/debian/tests/test-suite index cff9edf2..21797e58 100644 --- a/debian/tests/test-suite +++ b/debian/tests/test-suite @@ -2,5 +2,9 @@ set -e +cp -a tests "$AUTOPKGTEST_TMP" +ln -s /usr/share/asymptote "$AUTOPKGTEST_TMP"/base +ln -s /usr/bin/asy "$AUTOPKGTEST_TMP"/asy + export ASYMPTOTE_HOME=$(mktemp -d) -make test \ No newline at end of file +make -C "$AUTOPKGTEST_TMP"/tests all
Bug#1061338: RFS: kvazaar/2.3.0-1 [ITP] -- HEVC encoder
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: pkg-multimedia-maintain...@lists.alioth.debian.org,sramac...@debian.org (CC'ing pkg-multimedia-maintainers as the group where I'm planning to maintain it and Sebastian who sponsored other packages from me) Dear mentors, I am looking for a sponsor for my package "kvazaar": * Package name : kvazaar Version : 2.3.0-1 Upstream contact : https://ultravideo.fi/#encoder * URL : https://github.com/ultravideo/kvazaar * License : BSD-2-clause, ISC, BSD-3-clause * Vcs : https://salsa.debian.org/multimedia-team/kvazaar Section : libs The source builds the following binary packages: kvazaar - HEVC encoder - application libkvazaar7 - HEVC encoder - shared library libkvazaar-dev - HEVC encoder - development files kvazaar-doc - HEVC encoder - documentation Note: the packaging files (for now) are available at https://salsa.debian.org/fancycode/kvazaar I'm planning to move this to the "multimedia-team" group once packaging is final. Package "hm" is required for building to run the tests from kvazaar. See bug 1060809 for the RFS status of "hm". To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kvazaar/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kvazaar/kvazaar_2.3.0-1.dsc Changes for the initial release: kvazaar (2.3.0-1) unstable; urgency=medium . * Initial release. (Closes: #1060341) Regards, -- Joachim Bauch OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Am 21.01.2024 um 15:25 schrieb Helmut Grohne: > Source: glibc > Version: 2.37-13 > Tags: patch > User: helm...@debian.org > Usertags: dep17m2 > > Hi Aurelien, > > thanks for your answers on IRC to my design question. As promised here > comes a patch that moves most files in binary packages built from glibc > from aliased locations to /usr. This excludes the runtime dynamic linker > for native libc packages (i.e. not multilib), because moving it would > break filesystem bootstrap unless base-files installs the aliasing > symlinks at the same time. I have not studied the details, but this looks rather dangerous to me. If you install the runtime dynamic linker in multilib packages below /usr, but keep the native one at its current place, you risk losing it when the multilib packages are removed. For instance, I have both libc6:i386 and libc6-i386:amd64 installed. If the latter starts shipping /usr/lib/ld-linux.so.2 rather than /lib/ld-linux.so.2, the "Replaces" in libc6:i386 becomes ineffective, and we have basically a case of Dep17 P1. True, there is already a file loss problem today. If I were to remove libc6:i386 now, I would be left without /lib/ld-linux.so.2 as well. But in such a situation it is always possible to remedy the situation by reinstalling libc6-i386. This is not ensured if only libc6-i386 is removed, as essential programs might depend on libc6:i386, leaving no easy way of recovery. Cheers, Sven
Bug#1061259: fbset: Move programs to /usr/bin
Package: fbset Version: 2.1-33 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Your package installs programs into /bin. For the ongoing Debian UsrMerge effort [1] these files should be relocated to /usr/bin in the trixie cycle. The simplest way to achieve that is probably to use the dh_movetousr tool added in debhelper 13.11.7, see the attached patch. Cheers, Sven [1] https://wiki.debian.org/UsrMerge From 4f14a04ac48d09e942ee25349862772c7e9448db Mon Sep 17 00:00:00 2001 From: Sven Joachim Date: Sun, 21 Jan 2024 17:37:15 +0100 Subject: [PATCH] Move binaries below /usr The upstream Makefile installs binaries into /bin, in Debian trixie and later they should be installed into /usr/bin instead. Use the dh_movetousr tool added in debhelper 13.11.7 to achieve that. Adding dh-sequence-movetousr to Build-Depends is not strictly necessary, but it helps with backports and ensures that dh_movetousr is run in case debian/rules gets ever converted to dh. --- debian/control | 2 +- debian/rules | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 91d1c9f..a53e199 100644 --- a/debian/control +++ b/debian/control @@ -7,7 +7,7 @@ Vcs-Browser: https://github.com/sudipm-mukherjee/fbset.git Vcs-Git: https://github.com/sudipm-mukherjee/fbset.git Standards-Version: 4.6.1.0 Rules-Requires-Root: no -Build-Depends: debhelper-compat (= 13), dpkg-dev (>= 1.15.7), flex, bison +Build-Depends: debhelper-compat (= 13), dh-sequence-movetousr, dpkg-dev (>= 1.15.7), flex, bison Package: fbset Architecture: linux-any diff --git a/debian/rules b/debian/rules index 543d5f2..1d0a590 100755 --- a/debian/rules +++ b/debian/rules @@ -79,6 +79,7 @@ binary-arch: install-arch dh_strip -a dh_compress -a dh_fixperms -a + dh_movetousr -a dh_installdeb -a dh_shlibdeps -a dh_gencontrol -a -- 2.43.0
Bug#1061121: di-utils-terminfo: should include xterm-256color terminfo entry
Control: tags -1 + patch On 2024-01-18 19:32 +0100, Sven Joachim wrote: > Package: di-utils-terminfo > Version: 1.148 > Control: block 887649 by -1 > > Please include the xterm-256color in di-utils-terminfo. AFAICS this is > a prerequisite for fixing #887649, because vte2.91 sets the TERM > environment variable to xterm-256color by default[1,2], while the old > vte package sets TERM=xterm. > > In case anyone has unrealistically high hopes: I can send a patch for > the current bug, but do not volunteer to fix #887649. A trivial patch is attached, and I have also created a merge request on Salsa: https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/9. Cheers, Sven From 400104fa5f45f4464311ec499716786ab1f4a5df Mon Sep 17 00:00:00 2001 From: Sven Joachim Date: Sun, 21 Jan 2024 13:05:17 +0100 Subject: [PATCH] Include the xterm-256color terminfo entry in di-utils-terminfo This is a prerequisite for switching from the old unmaintained vte package to vte2.91, as the latter sets TERM to xterm-256color by default. Closes: #1061121 --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index c7278c7..ed9690c 100755 --- a/debian/rules +++ b/debian/rules @@ -17,7 +17,7 @@ export DEB_CFLAGS_MAINT_APPEND := -Wall -W -Os -fomit-frame-pointer CFLAGS := $(shell dpkg-buildflags --get CPPFLAGS; dpkg-buildflags --get CFLAGS) LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS) -TERMNAMES = a/ansi d/dumb s/screen x/xterm +TERMNAMES = a/ansi d/dumb s/screen x/xterm x/xterm-256color ifeq ($(DEB_HOST_ARCH_OS),linux) TERMNAMES += l/linux -- 2.43.0
Bug#1060985: prewikka: FTBFS: ModuleNotFoundError: No module named 'six'
tags 1060985 patch thanks Looks like the package has a missing build dependency on python3-six. Builds successfully with the attached patch. -- mvh / best regards Hans Joachim Desserud http://desserud.orgdiff --git a/debian/control b/debian/control index 403eaea..59746b8 100644 --- a/debian/control +++ b/debian/control @@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13), python3-setuptools, python3-babel, python3-lesscpy, +python3-six, gettext, Standards-Version: 4.6.0 Homepage: https://www.prelude-siem.org/
Bug#1061151: asymptote: should run tests at build time
Am 20.01.2024 um 10:22 schrieb Preuße, Hilmar: > On 19.01.2024 18:04, Sven Joachim wrote: >> On 2024-01-19 17:11 +0100, Sven Joachim wrote: > > Hi Sven, > >>> Your package has a test suite that probably should be run at build time, >>> but it is not. I looked at the git repository and found that it has >>> been disabled since at least 2015: >>> >>> , >>> | $ git show f69991bf3 >>> | commit f69991bf3cf85c0560ac93a2b24d96ce67c061d9 >>> | Author: Norbert Preining >>> | Date: Tue Jun 23 08:41:59 2015 +0900 >>> | >>> | do not do testing >>> | >>> | diff --git a/debian/rules b/debian/rules >>> | index 6d9d7387..2d52d8f6 100755 >>> | --- a/debian/rules >>> | +++ b/debian/rules >>> | @@ -22,6 +22,9 @@ override_dh_auto_install: >>> | make install-asy DESTDIR=$(CURDIR)/debian/tmp >>> | dh_installtex -pasymptote >>> | >>> | +override_dh_auto_test: >>> | + : do nothing here, otherwise make tries to compile prc/test.cc >>> | + >>> | override_dh_clean: >>> | dh_clean >>> | rm --force doc/latexusage.pdf doc/latexusage.dvi >>> doc/TeXShopAndAsymptote.dvi doc/CAD.dvi >>> ` >>> >>> This leaves me rather puzzled: why exactly would it bad if make tries to >>> compile prc/test.cc? >> Out of curiosity, I removed the dh_auto_test override and built the >> package with "sbuild --no-arch-all". This ran the test suite where >> various files were compiled, but not prc/test.cc. The build was >> successful. >> > > As you noticed I did not enter that entry and the person who did that > does not actively work for Debian any more. Maybe at the time of the > commit the file prc/test.cc was still compiled and linked and that was > bad somehow. Perhaps. I am not too interested in doing archeology, what matters is that the comment clearly is wrong now. > Anyway I'd like to leave it as it is: there are some slow > architectures, hence I'd not run the test suite on all arches. The test suite takes only about 1% of the overall build time (in a fresh sbuild chroot where all the build dependencies have to be installed first, which takes quite long). Cheers, Sven
Bug#1061151: asymptote: should run tests at build time
On 2024-01-19 17:11 +0100, Sven Joachim wrote: > Source: asymptote > Version: 2.86+ds1-1 > > Your package has a test suite that probably should be run at build time, > but it is not. I looked at the git repository and found that it has > been disabled since at least 2015: > > , > | $ git show f69991bf3 > | commit f69991bf3cf85c0560ac93a2b24d96ce67c061d9 > | Author: Norbert Preining > | Date: Tue Jun 23 08:41:59 2015 +0900 > | > | do not do testing > | > | diff --git a/debian/rules b/debian/rules > | index 6d9d7387..2d52d8f6 100755 > | --- a/debian/rules > | +++ b/debian/rules > | @@ -22,6 +22,9 @@ override_dh_auto_install: > | make install-asy DESTDIR=$(CURDIR)/debian/tmp > | dh_installtex -pasymptote > | > | +override_dh_auto_test: > | + : do nothing here, otherwise make tries to compile prc/test.cc > | + > | override_dh_clean: > | dh_clean > | rm --force doc/latexusage.pdf doc/latexusage.dvi > doc/TeXShopAndAsymptote.dvi doc/CAD.dvi > ` > > This leaves me rather puzzled: why exactly would it bad if make tries to > compile prc/test.cc? Out of curiosity, I removed the dh_auto_test override and built the package with "sbuild --no-arch-all". This ran the test suite where various files were compiled, but not prc/test.cc. The build was successful. This was on amd64, and I have not tested binary-indep or full builds. You may want to upload to experimental first to see how other architectures work. Cheers, Sven
Bug#1061152: asymptote: autopkgtest should test installed package
Package: asymptote Version: 2.86+ds1-1 Your package's autopkgtest runs the upstream test suite which is nice. However, it first builds the program and then tests that, rather than the package from the archive. This is not very useful, as changes in reverse dependencies could cause breakage at runtime which might vanish after a rebuild. In #1061151 I have requested that the test suite be run at build time. Cheers, Sven
Bug#1061151: asymptote: should run tests at build time
Source: asymptote Version: 2.86+ds1-1 Your package has a test suite that probably should be run at build time, but it is not. I looked at the git repository and found that it has been disabled since at least 2015: , | $ git show f69991bf3 | commit f69991bf3cf85c0560ac93a2b24d96ce67c061d9 | Author: Norbert Preining | Date: Tue Jun 23 08:41:59 2015 +0900 | | do not do testing | | diff --git a/debian/rules b/debian/rules | index 6d9d7387..2d52d8f6 100755 | --- a/debian/rules | +++ b/debian/rules | @@ -22,6 +22,9 @@ override_dh_auto_install: | make install-asy DESTDIR=$(CURDIR)/debian/tmp | dh_installtex -pasymptote | | +override_dh_auto_test: | + : do nothing here, otherwise make tries to compile prc/test.cc | + | override_dh_clean: | dh_clean | rm --force doc/latexusage.pdf doc/latexusage.dvi doc/TeXShopAndAsymptote.dvi doc/CAD.dvi ` This leaves me rather puzzled: why exactly would it bad if make tries to compile prc/test.cc? Note that the test suite is run in an autopkgtest since version 2.73+ds-2, so it apparently works. Cheers, Sven
Bug#1004901: ncurses-bin: issues with the infocmp(1) man page and databases
On 2022-02-03 11:10 +0100, Vincent Lefevre wrote: > Package: ncurses-bin > Version: 6.3-2 > Severity: minor > > In the infocmp(1) man page: > >Changing Databases [-A directory] [-B directory] >Like other ncurses utilities, infocmp looks for the terminal >descriptions in several places. You can use the TERMINFO and >TERMINFO_DIRS environment variables to override the compiled-in >default list of places to search (see curses(3X) for details). > > The curses(3X) man page does not exist. It is curses(3ncurses). This particular problem has been fixed in version 6.3+20220423-1, probably as a consequence of the following change in the 20211225 patchlevel: , | + improve markup, e.g., for external manpage links in the manpages | (prompted by report by Helge Kreutzmann). ` As of version 6.4+20240113-1 there are no longer any '3X' references in any of the manpages, and I have also added an autopkgtest to ensure that they do not come back. > Moreover, > > FILES >/etc/terminfo Compiled terminal description database. > > It is empty in my case. It appears that infocmp looks at other places, > such as /lib/terminfo (most cases) and "$HOME/.terminfo". Yes. There are several places in the manpages where /etc/terminfo is referred to as the system terminfo database, but it is really just the place where tic(1) writes to by default, whereas the terminfo entries provided by the distribution usually live under /usr/share/terminfo. Someone™ should improve that, because it basically affects every Linux distro out there. > Instead of giving a directory that is not used in practice, give a > reference to the curses(3ncurses) man page? That would probably not be too helpful, because that manpage is likely not present. The "Fetching Compiled Descriptions" section in terminfo(5) is probably the most accurate reference. Cheers, Sven
Bug#1061121: di-utils-terminfo: should include xterm-256color terminfo entry
Package: di-utils-terminfo Version: 1.148 Control: block 887649 by -1 Please include the xterm-256color in di-utils-terminfo. AFAICS this is a prerequisite for fixing #887649, because vte2.91 sets the TERM environment variable to xterm-256color by default[1,2], while the old vte package sets TERM=xterm. In case anyone has unrealistically high hopes: I can send a patch for the current bug, but do not volunteer to fix #887649. Cheers, Sven 1. https://bugzilla.gnome.org/show_bug.cgi?id=740641 2. https://sources.debian.org/src/vte2.91/0.74.2-1/src/vtedefines.hh/?hl=144#L144
Bug#1060809: RFS: hm/18.0-1 [ITP] -- Reference software for HEVC
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: pkg-multimedia-maintain...@lists.alioth.debian.org X-Debbugs-Cc: sramac...@debian.org (CC'ing pkg-multimedia-maintainers as the group where I'm planning to maintain it and Sebastian who sponsored other packages from me) Dear mentors, I am looking for a sponsor for my package "hm": * Package name : hm Version : 18.0-1 Upstream contact : https://hevc.hhi.fraunhofer.de/ * URL : https://vcgit.hhi.fraunhofer.de/jvet/HM * License : public-domain, BSD-3-clause * Vcs : https://salsa.debian.org/multimedia-team/hm Section : video The source builds the following binary packages: hm - Reference software for HEVC - standard bitdepth hm-highbitdepth - Reference software for HEVC - high bitdepth hm-config - Reference software for HEVC - config files hm-doc - Reference software for HEVC - documentation Note: the packaging files (for now) are available at https://salsa.debian.org/fancycode/hm I'm planning to move this to the "multimedia-team" group once packaging is final. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hm/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hm/hm_18.0-1.dsc Changes for the initial release: hm (18.0-1) unstable; urgency=medium . * Initial release. (Closes: #1060678) Thanks and best regards, Joachim OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060448: debcheckout: deprecation warnings with perl 5.38
On 2024-01-11 17:59 +0100, Sven Joachim wrote: > Package: devscripts > Version: 2.23.7 > > After upgrading perl from 5.36.0 to 5.38.2, debcheckout displays some > twenty deprecation warnings: > > , > | $ debcheckout etckeeper > | given is deprecated at /usr/bin/debcheckout line 419. > | when is deprecated at /usr/bin/debcheckout line 420. > | when is deprecated at /usr/bin/debcheckout line 424. > | given is deprecated at /usr/bin/debcheckout line 464. > | when is deprecated at /usr/bin/debcheckout line 465. > | when is deprecated at /usr/bin/debcheckout line 469. > | given is deprecated at /usr/bin/debcheckout line 513. > | when is deprecated at /usr/bin/debcheckout line 514. > | when is deprecated at /usr/bin/debcheckout line 515. > | when is deprecated at /usr/bin/debcheckout line 516. > | when is deprecated at /usr/bin/debcheckout line 522. > | when is deprecated at /usr/bin/debcheckout line 523. > | when is deprecated at /usr/bin/debcheckout line 547. > | when is deprecated at /usr/bin/debcheckout line 548. > | given is deprecated at /usr/bin/debcheckout line 605. > | when is deprecated at /usr/bin/debcheckout line 606. > | when is deprecated at /usr/bin/debcheckout line 637. > | when is deprecated at /usr/bin/debcheckout line 682. > | when is deprecated at /usr/bin/debcheckout line 700. > | when is deprecated at /usr/bin/debcheckout line 761. > ` > > According to the perldeprecation manpage, "given" and "when" are > scheduled for removal in Perl 5.42: > > , > |Perl 5.42 > |Smartmatch > | > |Smartmatch is now seen as a failed experiment and was marked as > |deprecated in Perl 5.37.10. This includes the "when" and "given" > |keywords, as well as the smartmatch operator "~~". The feature > |will be removed entirely in the Perl 5.42.0 production release. > | > |Category: "deprecated::smartmatch" > ` There is one more program in devscripts which uses the hitherto experimental and now deprecated keywords, namely chdist: , | $ chdist -h > /dev/null | given is deprecated at /usr/bin/chdist line 710. | when is deprecated at /usr/bin/chdist line 711. | when is deprecated at /usr/bin/chdist line 714. | when is deprecated at /usr/bin/chdist line 717. | when is deprecated at /usr/bin/chdist line 720. | when is deprecated at /usr/bin/chdist line 723. | when is deprecated at /usr/bin/chdist line 726. | when is deprecated at /usr/bin/chdist line 729. | when is deprecated at /usr/bin/chdist line 732. | when is deprecated at /usr/bin/chdist line 735. | when is deprecated at /usr/bin/chdist line 738. | when is deprecated at /usr/bin/chdist line 741. | when is deprecated at /usr/bin/chdist line 744. | when is deprecated at /usr/bin/chdist line 747. | when is deprecated at /usr/bin/chdist line 750. | when is deprecated at /usr/bin/chdist line 753. | when is deprecated at /usr/bin/chdist line 756. | when is deprecated at /usr/bin/chdist line 759. | when is deprecated at /usr/bin/chdist line 762. ` Cheers, Sven
Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display
Control: clone -1 -2 Control: reassign -2 libperl5.38 Control: found -2 5.38.2-2 Control: retitle -2 When embedding Perl in C, the locale is switched to C/ASCII Control: forwarded -2 https://github.com/Perl/perl5/issues/21366 On 2024-01-11 23:06 +0100, gregor herrmann wrote: > On Thu, 11 Jan 2024 20:52:16 +0100, Sven Joachim wrote: > >> > After upgrading rxvt-unicode today, it's no longer displaying UTF-8 >> > properly. /var/log/apt/history.log shows: >> > Upgrade: rxvt-unicode:amd64 (9.31-1, 9.31-1+b1) > > Same here. Which made me quite nervous until I found this bug report > :) > >> I have not tested it, but the attached patch should fix that. See >> http://lists.schmorp.de/pipermail/rxvt-unicode/2023q3/002665.html. > > I've rebuilt rxvt-unicode with this patch and I can confirm that it > seems to work for all cases I've suffered from before. > > I think a quick upload would be good to spare all the people running > unstable & updating perl to 5.38 in the next hours the troubles :) Speaking of Perl 5.38, this bug is actually a problem in Perl. The rxvt-unicode patch just works around it. According to the Perl upstream bug (https://github.com/Perl/perl5/issues/21366), at least one other application (irssi) is affected. Fedora has apparently reverted a commit in Perl to fix the problem, see https://src.fedoraproject.org/rpms/perl/c/dee564d443debbf47127d668f0982165835d873b. Cheers, Sven
Bug#1060678: ITP: hm - reference software for HEVC
Package: wnpp Severity: wishlist Owner: Joachim Bauch X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: hm Version : 18.0 Upstream Author : Joint Video Experts Team (JVET), ITU/ISO/IEC * URL : https://vcgit.hhi.fraunhofer.de/jvet/HM * License : BSD 3-Clause Programming Lang: C++ Description : HM reference software for HEVC This software package is the reference software for Rec. ITU-T H.265 | ISO/IEC 23008-2 High Efficiency Video Coding (HEVC). The reference software includes both encoder and decoder functionality. Reference software is useful in aiding users of a video coding standard to establish and test conformance and interoperability, and to educate users and demonstrate the capabilities of the standard. For these purposes, this software is provided as an aid for the study and implementation of Rec. ITU-T H.265 | ISO/IEC 23008-2 High Efficiency Video Coding. The software has been jointly developed by the ITU-T Video Coding Experts Group (VCEG, Question 6 of ITU-T Study Group 16) and the ISO/IEC Moving Picture Experts Group (MPEG, Working Group 11 of Subcommittee 29 of ISO/IEC Joint Technical Committee 1). The software is maintained by the Joint Video Experts Team (JVET) which is a joint collaboration of ITU-T Video Coding Experts Group (VCEG, Question 6 of ITU-T Study Group 16) and the ISO/IEC Moving Picture Experts Group (MPEG, Working Group 5 of Subcommittee 29 of ISO/IEC Joint Technical Committee 1). If "hm" is too short as a package name, I could name it "hm-hevc" or something similar. "hm" is used for automated tests of "kvazaar" (see #1060341), so I would like to be able to build-depend on the to-be-packaged "hm" from "kvazaar" to run the tests also during packaging. I'm planing to maintain the packaging from the Multimedia Team which I'm already a member of. For the first release I will need a sponsor, but I'm planning to apply to become a DD in the near future, so hopefully at that point I can maintain it without external help. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display
On 2024-01-11 19:18 +, Michael Gold wrote:
> Package: rxvt-unicode
> Version: 9.31-1+b1
> Severity: important
>
> Dear Maintainer,
>
> After upgrading rxvt-unicode today, it's no longer displaying UTF-8
> properly. /var/log/apt/history.log shows:
> Upgrade: rxvt-unicode:amd64 (9.31-1, 9.31-1+b1)
>
> I still have an old window open, in which this command:
> printf '\xe2\x80\x94\n'
> properly produces an EM DASH (U+2014); in the newer version, it produces
> U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX.
>
> Another simple test is to run "mc" and note that all the box-drawing
> characters are corrupted.
I have not tested it, but the attached patch should fix that. See
http://lists.schmorp.de/pipermail/rxvt-unicode/2023q3/002665.html.
Cheers,
Sven
diff --git a/src/rxvtperl.xs b/src/rxvtperl.xs
index ba697f0..ce02b59 100644
--- a/src/rxvtperl.xs
+++ b/src/rxvtperl.xs
@@ -399,7 +399,7 @@ rxvt_perl_interp::init ()
{
if (!perl)
{
- rxvt_push_locale (""); // perl init destroys current locale
+ rxvt_push_locale ("C"); // perl init destroys current locale
{
perl_environ = rxvt_environ;
Bug#1060448: debcheckout: deprecation warnings with perl 5.38
Package: devscripts Version: 2.23.7 After upgrading perl from 5.36.0 to 5.38.2, debcheckout displays some twenty deprecation warnings: , | $ debcheckout etckeeper | given is deprecated at /usr/bin/debcheckout line 419. | when is deprecated at /usr/bin/debcheckout line 420. | when is deprecated at /usr/bin/debcheckout line 424. | given is deprecated at /usr/bin/debcheckout line 464. | when is deprecated at /usr/bin/debcheckout line 465. | when is deprecated at /usr/bin/debcheckout line 469. | given is deprecated at /usr/bin/debcheckout line 513. | when is deprecated at /usr/bin/debcheckout line 514. | when is deprecated at /usr/bin/debcheckout line 515. | when is deprecated at /usr/bin/debcheckout line 516. | when is deprecated at /usr/bin/debcheckout line 522. | when is deprecated at /usr/bin/debcheckout line 523. | when is deprecated at /usr/bin/debcheckout line 547. | when is deprecated at /usr/bin/debcheckout line 548. | given is deprecated at /usr/bin/debcheckout line 605. | when is deprecated at /usr/bin/debcheckout line 606. | when is deprecated at /usr/bin/debcheckout line 637. | when is deprecated at /usr/bin/debcheckout line 682. | when is deprecated at /usr/bin/debcheckout line 700. | when is deprecated at /usr/bin/debcheckout line 761. ` According to the perldeprecation manpage, "given" and "when" are scheduled for removal in Perl 5.42: , |Perl 5.42 |Smartmatch | |Smartmatch is now seen as a failed experiment and was marked as |deprecated in Perl 5.37.10. This includes the "when" and "given" |keywords, as well as the smartmatch operator "~~". The feature |will be removed entirely in the Perl 5.42.0 production release. | |Category: "deprecated::smartmatch" ` -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#1060392: etckeeper: move systemd units into /usr
Package: etckeeper Version: 1.18.20-1.1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi, Your package installs systemd units into /lib/systemd/system. For the ongoing Debian UsrMerge effort [1] these files should move to /usr in the trixie cycle. There are several ways to achieve this, the simplest one is probably to add dh-sequence-movetousr to Build-Depends, so that the helper tool dh_movetousr does the job. See the attached build-tested patch. Cheers, Sven [1] https://wiki.debian.org/UsrMerge From 7b9cbc1f9e6b12d1c367eaac176c007d24f1ac81 Mon Sep 17 00:00:00 2001 From: Sven Joachim Date: Wed, 10 Jan 2024 17:31:53 +0100 Subject: [PATCH] Build-depend on dh-sequence-movetousr This moves the systemd units into /usr/lib/systemd/system in trixie and later, while keeping them in /lib/systemd/system in bookworm-backports. --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index 3729659..8d0cb4b 100644 --- a/debian/control +++ b/debian/control @@ -5,6 +5,7 @@ Build-Depends: debhelper-compat (= 13), bats, brz, dh-python, + dh-sequence-movetousr, fakeroot, git, python3:any, -- 2.43.0
Bug#1060341: ITP: kvazaar -- Kvazaar is an open-source HEVC encoder
Package: wnpp Severity: wishlist Owner: Joachim Bauch X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: kvazaar Version : 2.2.0 Upstream Author : Ari Lemmetti, Marko Viitanen, Alexandre Mercat, Jarno Vanne * URL : https://github.com/ultravideo/kvazaar * License : BSD 3-Clause Programming Lang: C, C++, ASM Description : Kvazaar is an open-source HEVC encoder Kvazaar is an award-winning academic open-source video encoder for the state-of-the-art High Efficiency Video Coding (HEVC/H.265) standard developed since 2012. Kvazaar is being developed in C and optimized in SSE/AVX intrinsics under the BSD-3-Clause license since v2.1. The development is being coordinated by Ultra Video Group and the implementation work is carried out on GitHub. The main development goals of Kvazaar are: - Coding efficiency close to HM - Easy portability to various platforms - Real- time coding speed - Optimized computation and memory resources Kvazaar includes all coding tools of Main, Main 10, and Main Still Picture profiles of HEVC and its modular source code facilitates parallelization on multi and manycore processors as well as algorithm acceleration on hardware. This cross-platform HEVC encoder is targeted at x86, x64, PowerPC, and ARM processors on Windows, Linux, and Mac. Kvazaar is also supported by de-facto standard multimedia frameworks FFmpeg and Libav. My main motivation for packaging Kvazaar is to be able to use it from the corresponding libheif plugin, but it could also be used by FFmpeg and Livav. A similar package would be x265 which is GPL licensed where Kvazaar uses BSD license. Kvazaar is faster than x265 for various inputs. I'm planing to maintain it from the Multimedia Team which I'm already a member of. For the first release I will need a sponsor, but I'm planning to apply to become a DD in the near future, so hopefully at that point I can maintain it without external help. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060211: libncurses-dev: ncurses6-config manpage references curses(3X)
Package: libncurses-dev Version: 6.4+20231209-1 Severity: minor The ncurses6-config manpage references curses(3X) rather than ncurses(3NCURSES) as it should. , | $ man ncursesw6-config | grep -A1 "SEE ALSO" | SEE ALSO |ncurses(3NCURSES) | $ man ncurses6-config | grep -A1 "SEE ALSO" | SEE ALSO |curses(3X) ` The reason is that ncurses6-config.1 is installed directly from the build tree via debian/libncurses-dev.manpages, while ncursesw6-config.1 has been changed by "make install". We have been doing this for many years, it goes all the way back to version 5.7+20100313-1. Compare commit c8d4cb3d2f99 where this scheme was introduced: , | Author: Sven Joachim | Date: Sun Mar 14 08:36:49 2010 +0100 | | Install ncursesw5-config manpage | | Since we're calling "make install.libs" rather than "make install" in | the obj-wide directory, ncursesw5-config.1 does not get installed into | debian/tmp. So we let dh_installman do the job. `
Bug#1060144: man-db: move systemd units into /usr
Package: man-db Version: 2.12.0-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi, Your package installs systemd units into /lib/systemd/system. For the ongoing Debian UsrMerge effort [1] these files should move to /usr in the trixie cycle. It seems that almost everything is in place for that already and all that is needed is to add systemd-dev to Build-Depends, so that systemd.pc decides on the location of the unit files. See the attached build-tested patch. Cheers, Sven [1] https://wiki.debian.org/UsrMerge From 292037fa4fe629a25f9cfbe9e436688d9cdc99da Mon Sep 17 00:00:00 2001 From: Sven Joachim Date: Sat, 6 Jan 2024 12:49:09 +0100 Subject: [PATCH] Add systemd-dev to Build-Depends This ensures that the systemd units are installed into /usr/lib/systemd/system in trixie and later, while keeping them in /lib/systemd/system in bookworm-packports. --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index ff9b9ac8..295bea78 100644 --- a/debian/control +++ b/debian/control @@ -13,6 +13,7 @@ Build-Depends: autopoint, libpipeline-dev, libseccomp-dev [amd64 arm64 armel armhf hppa i386 mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x x32], pkg-config, + systemd-dev [linux-any], po4a, zlib1g-dev, Homepage: https://man-db.gitlab.io/man-db/ -- 2.43.0
Bug#618429: ncurses-doc: no 3x man pages in /usr/share/man/man3
On 2011-03-17 18:05 -0400, Thomas Dickey wrote: > On Wed, 16 Mar 2011, Sven Joachim wrote: > >> On 2011-03-15 03:54 +0100, Vincent Lefevre wrote: >> >>> Package: ncurses-doc >>> Version: 5.8+20110307-1 >> >> Note that none of this is new, the same problem exists in the >> libncurses5-dev package in squeeze and lenny which held the >> documentation before I split it out to ncurses-doc. >> >>> ncurses-doc has /usr/share/doc/ncurses-doc/html/man/*.3x.html files, >>> but not the corresponding man pages in /usr/share/man/man3. >> >> More exactly, the manpages are there, but not under the same names. >> This is because they are renamed (see man/man_db.renames in the ncurses >> source tree), while the HTML documentation does not receive such >> treatment. >> >> I don't know why this setup with renaming manpages exists, but it has >> been around at least since ncurses 4.1, released 1997. > > Before that - man_db.renames was added in October 1995. At that point, > only the files were renamed (no link-fixes), and I added the edit_man.sh > script in mid-1996 (I seem to recall that was to obsolete some scripting > in the Debian package - or perhaps I'm recalling some later refinement). > > My understanding was that it was done that way to follow some Debian > guideline. There is an old thread about that topic from 1996 on debian-devel[1]. The main reason for renaming the manpages has been stated by Richard Kettlewell[2] and confirmed by Ian Jackson[3]: , | Isn't it a good thing that you can say man and get the | right man page, rather than having to say man curs_, | though? ` >>> Note that some other man pages, e.g. reset(1), have references to >>> such man pages in the "SEE ALSO" section, so that it is annoying >>> not to have access to these man pages with "man". >> >> This is a fallout from the following change mentioned in NEWS: >> >> , >> | 20061230 >> | [...] >> |+ used linklint to verify links in the HTML documentation, made fixes >> | to manpages as needed. >> ` >> >> That change fixed the links in the HTML documentation, but broke the >> references in the manpages themselves. There have been more of such issues, for instance #1004901 and #1057651. However, thanks to Branden Robinson's work on the manpages in recent months, all but one reference should be fixed in the latest patchlevel. I just sent a patch upstream for the last one[4]. > The html documentation _could_ be generated to be consistent with the > manpages, but that would complicate the Debian package... Apparently we would need to package or vendor your version of man2html and run it with suitable options on the installed manpages. There does not seem to be a dedicated target in the Makefiles to regenerate the HTML documentation, if I understand correctly this is done as part of "make dist". Certainly that is not impossible, but it is also something I am not exactly keen on. Cheers, Sven 1. https://lists.debian.org/debian-devel/1996/06/threads.html#00281 2. https://lists.debian.org/debian-devel/1996/06/msg00364.html 3. https://lists.debian.org/debian-devel/1996/06/msg00393.html 4. https://lists.gnu.org/archive/html/bug-ncurses/2024-01/msg1.html
Bug#1057542: ap-utils: FTBFS: input.c:340:43: error: invalid application of ‘sizeof’ to incomplete type ‘ITEM’ {aka ‘struct tagITEM’}
On 2023-12-05 23:03 +0100, Santiago Vila wrote:
> Package: src:ap-utils
> Version: 1.5-5
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
> [snip]
>
> The above is just how the build ends and not necessarily the most relevant
> part.
Indeed, the actual error was missing. To work around the massive amount
of -Woverflow warnings (there are literally thousands of them), I added
-Wno-overflow to DEB_CFLAGS_MAINT_APPEND, and this is what I got:
,
| gcc -DHAVE_CONFIG_H -I. -I.. -I../intl -Wdate-time -D_FORTIFY_SOURCE=2 -g
-O2 -ffile-prefix-map=/usr/local/src/deb-src/ap-utils/ap-utils=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wall -pedantic -Wno-overflow
-Wno-error=format-security -Wall -W -c -o input.o input.c
| input.c: In function 'get_value':
| input.c:129:18: warning: variable 'y' set but not used
[-Wunused-but-set-variable]
| 129 | int c, i, x, y;
| | ^
| input.c: In function 'menu_choose':
| input.c:340:43: error: invalid application of 'sizeof' to incomplete type
'ITEM' {aka 'struct tagITEM'}
| 340 | ITEM **menu_item = calloc(num, sizeof(ITEM)), **ip = menu_item;
| | ^~~~
`
Since ncurses patchlevel 20231021 the ITEM structure is opaque, hence
its size is unknown to the compiler. This probably means that the
menu_choose() function needs some substantial changes. I have not
investigated further, if somebody cares about this package and the old
AP points it supports they will have to do the work.
Cheers,
Sven
Bug#864255: The licensing issue has been resolved
The licensing issue has been resolved by openssl 3 being availble under the Apache license v2.
Bug#1059395: libacl1, debhelper: changelog not detected as binNMU
On 2023-12-26 12:34 +0100, Gioele Barabucci wrote:
> Control: tags -1 moreinfo
> Control: retitle -1 libacl1, debhelper: changelog not detected as binNMU
>
> On Sun, 24 Dec 2023 14:27:22 + Simon McVittie wrote:
>> libacl1 was recently binNMU'd on all architectures to address version skew.
>> Unfortunately, the binNMU'd version is no longer multiarch co-installable
>> because its changelog differs between architectures:
>> │ │ ├── ./usr/share/doc/libacl1/changelog.Debian.gz
>> │ │ │ ├── changelog.Debian
>> │ │ │ │ @@ -1,13 +1,13 @@
>> │ │ │ │ acl (2.3.1-3+b1) sid; urgency=low, binary-only=yes
>> │ │ │ │
>> │ │ │ │ - * Binary-only non-maintainer upload for amd64; no source changes.
>> │ │ │ │ + * Binary-only non-maintainer upload for i386; no source changes.
>> │ │ │ │* Rebuild to sync binNMU versions
>> │ │ │ │
>> │ │ │ │ - -- all / amd64 / i386 Build Daemon (x86-conova-01) ...
>> │ │ │ │ + -- i386 Build Daemon (x86-grnet-01) ...
>> This binNMU changelog entry would normally be separated into
>> changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
>> /usr/share/doc/libxext6/ at the time of writing.
>
> dh_installchangelogs still has the same behavior as before when it
> comes to binNMU and their arch-specific changelogs, independent of the
> trimming logic.
That is not the case, AFAICS. This is what you installed in commit
af652db00:
,
| sub install_debian_changelog {
| my ($changelog, $package, $arch, $tmp) = @_;
|
| if ($dh{NO_TRIM} || get_buildoption("notrimdch")) {
| # Install the whole changelog.
| install_file($changelog,
"$tmp/usr/share/doc/$package/$changelog_name");
| return;
| }
`
All the binnmu handling happens _after_ that.
> What seems to have happened here is that the binNMU detection
> failed.
No, the logic in install_debian_changelog is incorrect and does not
handle biNMU entries at all if the changelog is not trimmed.
Cheers,
Sven
Bug#1057580: nfstrace: FTBFS: error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}
Control: tags -1 + patch
On 2023-12-05 23:07 +0100, Santiago Vila wrote:
> Package: src:nfstrace
> Version: 0.4.3.2+git20200805+b220d04-2.2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [ 7%] Building CXX object
> analyzers/src/watch/CMakeFiles/watch.dir/nc_windows/header_window.cpp.o
> cd /<>/obj-x86_64-linux-gnu/analyzers/src/watch && /usr/bin/c++
> -Dwatch_EXPORTS -I/<>/src -I/usr/include/tirpc
> -I/<>/analyzers/src/watch -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -pedantic -Wall -Werror -Wextra
> -Wno-invalid-offsetof -Wno-error=address-of-packed-member -fPIC
> -fvisibility=hidden -fPIC -MD -MT
> analyzers/src/watch/CMakeFiles/watch.dir/nc_windows/header_window.cpp.o -MF
> CMakeFiles/watch.dir/nc_windows/header_window.cpp.o.d -o
> CMakeFiles/watch.dir/nc_windows/header_window.cpp.o -c
> /<>/analyzers/src/watch/nc_windows/header_window.cpp
> /<>/analyzers/src/watch/nc_windows/header_window.cpp: In member
> function ‘void HeaderWindow::resize(MainWindow&)’:
> /<>/analyzers/src/watch/nc_windows/header_window.cpp:90:72:
> error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}
>90 | _window = subwin(m._window,
> std::min(static_cast(m._window->_maxy), GUI_HEADER_HEIGHT),
> std::min(static_cast(m._window->_maxx), GUI_LENGTH), 0, 0);
> |
> ^~
> In file included from
> /<>/analyzers/src/watch/nc_windows/header_window.h:25,
> from
> /<>/analyzers/src/watch/nc_windows/header_window.cpp:28:
> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka
> ‘struct _win_st’}
> 442 | typedef struct _win_st WINDOW;
> |^~~
> /<>/analyzers/src/watch/nc_windows/header_window.cpp:90:137:
> error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}
>90 | _window = subwin(m._window,
> std::min(static_cast(m._window->_maxy), GUI_HEADER_HEIGHT),
> std::min(static_cast(m._window->_maxx), GUI_LENGTH), 0, 0);
> |
> ^~
> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka
> ‘struct _win_st’}
> 442 | typedef struct _win_st WINDOW;
> |^~~
> make[3]: *** [analyzers/src/watch/CMakeFiles/watch.dir/build.make:79:
> analyzers/src/watch/CMakeFiles/watch.dir/nc_windows/header_window.cpp.o]
> Error 1
The attached patch fixes these errors and similar ones in
analyzers/src/watch/nc_windows/statistics_window.cpp. Note that
getmaxx(window) returns window->_maxx + 1, and similar for getmaxy().
Disclaimer: I have only tested that the package builds, not if it works.
Cheers,
Sven
From dcffbee1fa8170fdf6906791eb0239fac63e5333 Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Thu, 21 Dec 2023 17:12:56 +0100
Subject: [PATCH] Fix FTBFS with opqaque ncurses
Since ncurses patchlevel 20231021 the WINDOW structure is opaque, its
members cannot be addressed directly. Use the getmaxy/getmaxx
functions ncurses provides for this purpose instead.
---
analyzers/src/watch/nc_windows/header_window.cpp | 2 +-
analyzers/src/watch/nc_windows/statistics_window.cpp | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/analyzers/src/watch/nc_windows/header_window.cpp b/analyzers/src/watch/nc_windows/header_window.cpp
index a376488..047d555 100644
--- a/analyzers/src/watch/nc_windows/header_window.cpp
+++ b/analyzers/src/watch/nc_windows/header_window.cpp
@@ -87,7 +87,7 @@ void HeaderWindow::resize(MainWindow& m)
}
if(m._window != nullptr)
{
-_window = subwin(m._window, std::min(static_cast(m._window->_maxy), GUI_HEADER_HEIGHT), std::min(static_cast(m._window->_maxx), GUI_LENGTH), 0, 0);
+_window = subwin(m._window, std::min(static_cast(getmaxy(m._window) - 1 ), GUI_HEADER_HEIGHT), std::min(static_cast(getmaxx(m._window) - 1 ), GUI_LENGTH), 0, 0);
}
if(_window != nullptr)
{
diff --git a/analyzers/src/watch/nc_windows/statistics_window.cpp b/analyzers/src/watch/nc_windows/statistics_window.cpp
index b580bba..c2e27fc 100644
--- a/analyzers/src/watch/nc_windows/statistics_window.cpp
+++ b/analyzers/src/watch/nc_windows/statistics_window.cpp
@@ -50,7 +50,7 @@ void StatisticsWindow::destroy()
bool StatisticsWindow::canW
Bug#1057554: dradio: FTBFS: invalid use of incomplete typedef ‘ITEM’ {aka ‘struct tagITEM’}
Control: tags -1 + patch
On 2023-12-05 23:04 +0100, Santiago Vila wrote:
> Package: src:dradio
> Version: 3.8-2.1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -fcf-protection -c gui.c
> gui.c: In function ‘menu_create’:
> gui.c:236:20: error: invalid use of incomplete typedef ‘ITEM’ {aka ‘struct
> tagITEM’}
> 236 | menu_items[i]->userptr = conf_item; /* the xml conf */
> |^~
> make[3]: *** [Makefile:308: gui.o] Error 1
The attached patch fixes this, but I have only tested that dradio
builds, not if it works.
Cheers,
Sven
From 4baeee0b133b577e8c76dfec5bd92f77ba805bd9 Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Wed, 20 Dec 2023 17:13:56 +0100
Subject: [PATCH] Fix FTBFS with opaque ncurses
Since ncurses patchlevel 20231021 the ITEM structure is opaque, its
members cannot be addressed directly. Use the set_item_userptr
function instead.
---
src/gui.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gui.c b/src/gui.c
index 546b65e..0c16f45 100644
--- a/src/gui.c
+++ b/src/gui.c
@@ -233,7 +233,7 @@ MENU *menu_create()
while (conf_item)
{
menu_items[i] = new_item(conf_item->label, NULL);
- menu_items[i]->userptr = conf_item; /* the xml conf */
+ set_item_userptr(menu_items[i], conf_item); /* the xml conf */
conf_item = conf_item->next;
i--;
}
--
2.43.0
Bug#1057570: libgnt: FTBFS: error: invalid use of incomplete typedef ‘PANEL’ {aka ‘struct panel’}
Control: tags -1 + fixed-upstream
On 2023-12-05 23:06 +0100, Santiago Vila wrote:
> Package: src:libgnt
> Version: 2.14.3-2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [27/35] cc -Ilibgnt.so.0.14.3.p -I. -I.. -I/usr/include/ncursesw
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ
> libgnt.so.0.14.3.p/gntwm.c.o -MF libgnt.so.0.14.3.p/gntwm.c.o.d -o
> libgnt.so.0.14.3.p/gntwm.c.o -c ../gntwm.c
> FAILED: libgnt.so.0.14.3.p/gntwm.c.o
> cc -Ilibgnt.so.0.14.3.p -I. -I.. -I/usr/include/ncursesw
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ
> libgnt.so.0.14.3.p/gntwm.c.o -MF libgnt.so.0.14.3.p/gntwm.c.o.d -o
> libgnt.so.0.14.3.p/gntwm.c.o -c ../gntwm.c
> ../gntwm.c: In function ‘work_around_for_ncurses_bug’:
> ../gntwm.c:170:35: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 170 | sx = getbegx(panel->win);
> | ^~
> ../gntwm.c:171:35: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 171 | ex = getmaxx(panel->win) + sx;
> | ^~
> ../gntwm.c:172:35: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 172 | sy = getbegy(panel->win);
> | ^~
> ../gntwm.c:173:35: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 173 | ey = getmaxy(panel->win) + sy;
> | ^~
> ../gntwm.c:176:47: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 176 | if (sy > getbegy(below->win) +
> getmaxy(below->win) ||
> | ^~
> ../gntwm.c:176:69: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 176 | if (sy > getbegy(below->win) +
> getmaxy(below->win) ||
> | ^~
> ../gntwm.c:177:59: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 177 | ey < getbegy(below->win))
> | ^~
> ../gntwm.c:179:47: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 179 | if (sx > getbegx(below->win) +
> getmaxx(below->win) ||
> | ^~
> ../gntwm.c:179:69: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 179 | if (sx > getbegx(below->win) +
> getmaxx(below->win) ||
> | ^~
> ../gntwm.c:180:59: error: invalid use of incomplete typedef ‘PANEL’ {aka
> ‘struct panel’}
> 180 | ex < getbegx(below->win))
> | ^~
> [more errors snipped]
I have not tested it myself, but these errors should be fixed in libgnt
2.14.4 which has been released upstream the other day. See
https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which
explicitly mentions this bug.
Cheers,
Sven
Bug#1058960: dpkg: warning: unable to delete old directory '/usr/share/debian-reference': Directory not empty
On 2023-12-18 22:57 +0100, Christoph Anton Mitterer wrote: > Package: debian-reference > Version: 2.109 > Severity: normal > > > Hey. > > Something looks odd with the package’s files registration in Debian. > On upgrade from 2.108 to 2.109 I got: > Unpacking debian-reference-common (2.109) over (2.108) ... > dpkg: warning: unable to delete old directory > '/usr/share/debian-reference/images': Directory not empty > Preparing to unpack .../01-debian-reference-en_2.109_all.deb ... > Unpacking debian-reference-en (2.109) over (2.108) ... > dpkg: warning: unable to delete old directory '/usr/share/debian-reference': > Directory not empty > > > And indeed, none of these files seem to belong to a Debian package: > $ dpkg -S /usr/share/debian-reference/images/* > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/caution.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/home.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/important.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/next.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/note.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/prev.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/tip.png > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/up.gif > dpkg-query: no path found matching pattern > /usr/share/debian-reference/images/warning.png > $ dpkg -S /usr/share/debian-reference/* > dpkg-query: no path found matching pattern > /usr/share/debian-reference/apa.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch01.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch02.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch03.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch04.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch05.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch06.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch07.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch08.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch09.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch10.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch11.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/ch12.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/debian-reference.css > dpkg-query: no path found matching pattern > /usr/share/debian-reference/debian-reference.en.pdf > dpkg-query: no path found matching pattern > /usr/share/debian-reference/debian-reference.en.txt.gz > dpkg-query: no path found matching pattern /usr/share/debian-reference/images > dpkg-query: no path found matching pattern > /usr/share/debian-reference/index.en.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/index.html > dpkg-query: no path found matching pattern > /usr/share/debian-reference/pr01.en.html > > These files do however seem to exist in the package, though registered as: > $ grep /usr/share/doc/debian-reference-common/docs > /var/lib/dpkg/info/debian-reference-common.list > /usr/share/doc/debian-reference-common/docs > /usr/share/doc/debian-reference-common/docs/.htaccess > /usr/share/doc/debian-reference-common/docs/debian-reference.css > /usr/share/doc/debian-reference-common/docs/images > /usr/share/doc/debian-reference-common/docs/images/caution.png > /usr/share/doc/debian-reference-common/docs/images/home.png > /usr/share/doc/debian-reference-common/docs/images/important.png > /usr/share/doc/debian-reference-common/docs/images/next.png > /usr/share/doc/debian-reference-common/docs/images/note.png > /usr/share/doc/debian-reference-common/docs/images/prev.png > /usr/share/doc/debian-reference-common/docs/images/tip.png > /usr/share/doc/debian-reference-common/docs/images/up.gif > /usr/share/doc/debian-reference-common/docs/images/warning.png > /var/lib/dpkg/info$ grep /usr/share/doc/debian-reference-common/docs > /var/lib/dpkg/info/debian-reference-en.list > /usr/share/doc/debian-reference-common/docs > /usr/share/doc/debian-reference-common/docs/apa.en.html > /usr/share/doc/debian-reference-common/docs/ch01.en.html > /usr/share/doc/debian-reference-common/docs/ch02.en.html > /usr/share/doc/debian-reference-common/docs/ch03.en.html > /usr/share/doc/debian-reference-common/docs/ch04.en.html > /usr/share/doc/debian-reference-common/docs/ch05.en.html > /usr/share/doc/debian-reference-common/docs/ch06.en.html >
