Bug#1056300: ITP: gaphas -- a diagramming widget library for python
Package: wnpp Severity: wishlist Owner: Alexandre Esse X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gaphas Version : 3.11.2 Upstream Contact: Arjan Molenaar * URL : https://github.com/gaphor/gaphas * License : Apache-2.0 Programming Lang: Python Description : a diagramming widget library for python Gaphas is a diagramming widget library for Python. Gaphas is a library that provides the user interface component (widget) for drawing diagrams. Diagrams can be drawn to screen and then easily exported to a variety of formats, including SVG and PDF. Gaphas is for example used by gaphor for UML drawing, RAFCON for state-machine based robot control, and ASCEND for solving mathematical models. The package should probably be maintained as part of the Debian Python Team: https://wiki.debian.org/Teams/PythonTeam
Bug#1056299: ITP: gaphor -- a simple UML/SysML modeling tool
Package: wnpp Severity: wishlist Owner: Alexandre Esse X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gaphor Version : 2.21.0 Upstream Contact: Arjan Molenaar * URL : https://github.com/gaphor/gaphor * License : Apache-2.0 Programming Lang: Python Description : a simple UML/SysML modeling tool Gaphor is a UML and SysML modeling application written in Python. It is designed to be easy to use, while still being powerful. Gaphor implements a fully-compliant UML 2 data model, so it is much more than a picture drawing tool. The package should probably be maintained as part of the Debian Python Team: https://wiki.debian.org/Teams/PythonTeam
Bug#1051939: ubpm_1.9.0+20230923-1_amd64.changes REJECTED
Hi, Re-uploaded to NEW with requested changes. On Thursday, October 26, 2023 12:37:25 P.M. CST Thorsten Alteholz wrote: > Hi Steve, > > On 26.10.23 05:23, Steven Robbins wrote: > > On Monday, October 23, 2023 1:00:09 P.M. CDT Thorsten Alteholz wrote: > >> Hi, > >> > >> please ask upstream to add all licenses of embedded stuff like > >> ./sources/plugins/shared/hidapi > > > > Could you expand on this request? Each file notes "At the discretion of > > the user of this library, this software may be licensed under the terms > > of the GNU General Public License v3, a BSD-Style license, ..." > > yes, but the sentence goes on: "..., or the original HIDAPI license as > outlined in the LICENSE.txt, > LICENSE-gpl3.txt, LICENSE-bsd.txt, and LICENSE-orig.txt" > > The GPL is ok, but the BSD-Style license is not at all unambiguous and > what is the contents of LICENSE.txt and LICENSE-orig.txt? > They should be "located at the root of the source distribution.", but > they are not, hence my request. Added the four licenses files in sources/plugins/shared/hidapi: LICENSE-bsd.txt LICENSE-gpl3.txt LICENSE-orig.txt LICENSE.txt Regarding the PDF files: > > Sorry, that is a clear miss on my part. I will clarify the license or > > remove these before re-uploading. PDF files have been removed. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1056191: usrmerge: provide more documentation for Debian Developers and system administrators
Hi!
Thanks for the reponse - I am impressed by your ability to respond
almost immediately! However, should the bug report be left open for a
while and not immediately closed? Are you willing to review/merge if
somebody else submits an improvement to the README at
https://salsa.debian.org/md/usrmerge?
I can read some frustration from your reply with references that the
information is already easily available somewhere ("This has already
been discussed at lenght among the people attending the related Debian
infrastructure.") and that Ubuntu's switch to usrmerge is common
knowledge (apparently happened in Ubuntu 20.04 based on
https://packages.ubuntu.com/search?suite=all=names=usrmerge)
and confidence in that the fork that Ubuntu maintains has not relevant
changes.
If you leave this bug report / request open and tag it as 'help
needed', maybe other people who can more easily relate to the
user/sysadmin perspective can step up and contribute documentation
improvements?
Bug#983831: Dead link at https://www.debian.org/consultants/
Hello Scott, we are checking this bug report very late, I am sorry for that. Il giorno mar, 02/03/2021 alle 02.32 +, Scott C. MacCallum ha scritto: > Package: www.debian.org > Name: www.callpaul.eu > URL: www.callpaul.eu > Location: Line 1733, Col 23 [...] As of today, the link is working. It has a self signed certificate, but it is working. May I just close this bug report? Thank you, Giuseppe
Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved
package: riseup-vpn severity: grave version: 0.21.11+ds1-5+b4 It misses a dependency on openvpn-systemd-resolved and on boomworm it was working after installing it. But on mobian trixie, which has systemd-resolved installed by default (through mobian-base), dns resolution fails when riseup vpn is connected. error log attached ;; communications error to 127.0.0.53#53: timed out ;; communications error to 127.0.0.53#53: timed out ;; no servers could be reached
Bug#1042428: lintian.debian.org off ?
> > This issue still exists. I would now have the need to send the url > > https://lintian.debian.org/tags/service-file-is-not-a-file to upstream > > developers to learn about this Lintian issue, but the URL does not > > serve any contents nor does it redirect to a new location. > > > > I am still willing to contribute the Apache/Nginx rewrite rules if > > somebody can point me to a code repository where I can read/contribute > > at like I announced on September 27th in this thread. > > I finally fixed this. Sorry for the delay. > > https://udd.debian.org/lintian?packages=entr has a link for each lintian > tag, that points to (e.g.) > https://udd.debian.org/lintian-tag.cgi?tag=superfluous-file-pattern > That page includes a description of the tag as well as all packages > affected by the tag. Thanks! Could you consider setting up also redirects from old url, as it seems that search engines had it indexed pretty well and tend to offer links to lintian.debian.org as the primary result on on searches for various Lintian errors? https://lintian.debian.org/tags/([a-z-]*)/?$ -> https://udd.debian.org/lintian-tag.cgi?tag=$1
Bug#1053476: [debian-mysql] Bug#1053476: galera-3: CVE-2023-5157
Hi Adrian,
On Sun, Nov 19, 2023 at 11:10:04PM +0200, Adrian Bunk wrote:
> On Thu, Oct 05, 2023 at 09:38:00PM +0200, Salvatore Bonaccorso wrote:
> > Hi Otto,
> >
> > Thanks for the quick followup.
> >
> > On Wed, Oct 04, 2023 at 08:59:31PM -0700, Otto Kekäläinen wrote:
> > > Thanks for reporting this Salvatore!
> > >
> > > Are you aware of what plans upstream has?
> >
> > We are not, basically we require your help for this report for
> > assessing the issue.
> >
> > > The Jira MDEV-25068 was fixed in Galera 26.4.12
> > > (https://releases.galeracluster.com/galera-4.12/release-notes-galera-26.4.12.txt)
> > > in 2022. i don't see any commits on
> > > https://github.com/codership/galera/commits/3.x since 2022. i will
> > > keep an eye for new upstream releases.
> > >
> > > I can also review/merge for all Debian and Ubuntu releases still in
> > > maintenance a patch if somebody wants to submit a Debian-specific fix
> > > at https://salsa.debian.org/mariadb-team/galera-3/-/merge_requests. On
> > > a quick look I did not find the 26.4.12 fix
> > > (https://github.com/search?q=repo%3Acodership%2Fgalera+MDEV-25068=commits)
> > > so I am not aware of any specific commit nor if it can be backported
> > > to 25.3.37
> >
> > Do you have a good upstream contact which you could reach out to ask
> > on more details, references to fixes, etc on the issue?
>
> I looked at it for LTS and galera-3 is not affected:
>
> The upstream fix for MDEV-25068 is
> https://github.com/codership/galera/commit/930c016108d7086b472ad7a8b9d0f6989202b48a
> (26.4.12)
>
> This is in code that was introduced in
> https://github.com/codership/galera/commit/c27596d06a221f6c14d36759c681149964008749
> (26.4.8) which was not backported to galera-3.
>
> The introducing commit merged assign_local_addr() and assign_remote_addr()
> into assign_addresses().
>
> The fix is to catch the error when assign_addresses() throws
> asio::system_error.
>
> The two callsites of assign_local_addr/assign_remote_addr in the old code
> in gcomm/src/asio_tcp.cpp are already (in 26.4.7 and 25.3.37):
> try
> {
> ...
> assign_local_addr()
> assign_remote_addr()
> ...
> }
> catch (asio::system_error& e)
> {
> ...
> }
Thanks for the analysis of the issue.
Regards,
Salvatore
Bug#810018: New Essential package procps-base
On Wed, 15 Nov 2023 at 23:03, Guillem Jover wrote:
> I'm all in for shrinking the essential-set. If there is consensus to
> switch pidof implementations that also seems fine to me in the abstract.
> But this shuffling around of essential-ness and new tiny packages and
> stuff seems a bit unnecessary to me, more so when this increases the
> bootstrapping-set. I'd also rather see instead a _proper_ transition to
> get sysvinit-utils out of the essential-set, and then at some later
> point procps can take over pidof.
>
There really is two options then:
1) Switch pidof to new Essential package procps-base THEN update/fix the
dependent packages
2) Update/fix the dependent packages THEN move pidof to standard procps.
Independent? of either: re-work init scripts to use start-stop-daemon
For people that want the standard pidof #1 is preferred, for people
concerned about Essential's size #2 is preferred.
Most of the pidof usage can be broken down into a few sets:
* Used in comments/documentation - can be ignored for "pidof is Essential"
purposes
* Used in init or pre/post scripts - should probably be using pidofproc
* Within their programs use something like system("pidof myprog")
and then there are a few other odd ones that don't fit into those three.
Then there's the following, which I guess complicates things:
>
> $ dpkg -S bin/pidof | cut -d: -f2
>/bin/pidof
>
I'm not sure what the complication is here.
Also why is killall5 not a candidate too?
There's no other implementation of killall5 though it is probably something
that could be done with one of the other /.*kill.*/ programs.
Significantly, I don't think there is any real dependency of this program
in other programs, codesearch seems to be only for documentation.
> I think the status_of_proc function could be switched to use
> start-stop-daemon (s-s-d) --status instead of pidofproc. To replace
> pidof inside pidofproc I guess s-s-d could grow some option to print
> the pid, I'd be happy to implement that. After doing a quick scan over
> codesearch.debian.org, I notice that it looks like many current uses
> of pidofproc should instead probably be using status_of_proc, and others
> seem to just be fetching the pid to then perform some action that could
> instead all be done directly with s-s-d.
>
I agree that this is a good idea. It will be more about removing the
Essential flag on any package.
- Craig
Bug#1043257: auctex: New upstream release 13.2
Hi Davide, "Davide G. M. Salvetti" writes: > tags 1043257 +confirmed +pending > thanks > >> XD == Xiyue Deng [2023-8-7] > > [...] > > XD> Dear maintainers, > > XD> A new upstream release of auctex has been available for a while, and > XD> I've prepared a (somewhat crude) merge request[1] with refreshed > XD> patches which maybe useful as a base to work on. > > Dear Xiyue, > > I reviewed your work: the patches have to be refreshed the way you did, > thanks. I'm working on 13.2 packaging right now and will upload soon. > > XD> There are still several lintian warnings that I haven't figured out > XD> how to fix > > I've worked on and fixed them. Glad to see you started working on this! BTW, would you consider maintaining auctex with the Emacsen team? I'm also considering elpify auctex so that it's compatible with use-package. Would be great if you are open to collaboration. -- Xiyue Deng
Bug#1056296: dash: redirecting stdout for current shell via 'exec' command didn't work correctly
Package: dash Version: 0.5.12-6 Severity: normal X-Debbugs-Cc: msl023...@gmail.com Please see the following test case: # cat redir-stdout-test.sh #!/bin/sh set -e rm -f /tmp/empty true > /tmp/empty exec 1<> /tmp/empty ls -l /proc/$$/fd/ 1>&2 # bash redir-stdout-test.sh total 0 lrwx-- 1 root root 64 Nov 20 05:08 0 -> /dev/pts/0 lrwx-- 1 root root 64 Nov 20 05:08 1 -> /tmp/empty lrwx-- 1 root root 64 Nov 20 05:08 2 -> /dev/pts/0 lr-x-- 1 root root 64 Nov 20 05:08 255 -> /root/src/redir-stdout-test.sh # dash redir-stdout-test.sh total 0 lrwx-- 1 root root 64 Nov 20 05:07 0 -> /dev/pts/0 lrwx-- 1 root root 64 Nov 20 05:07 1 -> /dev/pts/0 lr-x-- 1 root root 64 Nov 20 05:07 10 -> /root/src/redir-stdout-test.sh lrwx-- 1 root root 64 Nov 20 05:07 11 -> /tmp/empty lrwx-- 1 root root 64 Nov 20 05:07 2 -> /dev/pts/0 As the test case shows, I need to redirect stdout (file descriptor 1), but this failed in dash(1) without any warning. The same program works in bash(1) as expected. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64 Kernel: Linux 4.19.271-rivoreo-powerpc64-largepage (SMP w/176 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages dash depends on: ii debianutils 5.14 ii dpkg 1.22.0 ii libc62.37-12 dash recommends no packages. dash suggests no packages. -- no debconf information
Bug#1053021: Additional information
On Mon, Nov 20, 2023 at 05:06:22PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/java-team/dbus-java/-/merge_requests/1 Yes, and thank you for the update. I will upload with this patch soon. Cheers, tony signature.asc Description: PGP signature
Bug#1053021: Additional information
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/dbus-java/-/merge_requests/1
Bug#1053018: Additional information
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/closure-compiler/-/merge_requests/2
Bug#1056295: geeqie: webp images no longer viewable
Package: geeqie Version: 1:2.1-1 Severity: important Dear Maintainer, Upon recent update, webp images are no longer viewable Here is a file that is webp and previously viewable, but now gives an erro and doesnt view dean@wheeljack:~/pics$ file 271366_20211213110900.webp 271366_20211213110900.webp: RIFF (little-endian) data, Web/P image, VP8 encoding, 1333x1999, Scaling: [none]x[none], YUV color, decoders should clamp dean@wheeljack:~/pics$ geeqie 271366_20211213110900.webp Error reading GIF file: Unrecognized image file format This may be a library rather than geeqie itself, if so then please point me in the right direction -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.11-x64v3-xanmod1 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geeqie depends on: ii geeqie-common1:2.1-1 ii libarchive13 3.7.2-1 ii libc62.37-12 ii libcairo21.18.0-1 ii libdjvulibre21 3.5.28-2+b1 ii libexiv2-27 0.27.6-1 ii libffmpegthumbnailer4v5 2.2.2+git20220218+dfsg-2 ii libgcc-s113.2.0-6 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libglib2.0-0 2.78.1-4 ii libgspell-1-21.12.2-1 ii libgtk-3-0 3.24.38-6 ii libheif1 1.17.1-1+b1 ii libjpeg62-turbo 1:2.1.5-2 ii libjxl0.70.7.0-10.2 ii liblcms2-2 2.14-2 ii liblua5.3-0 5.3.6-2 ii libopenjp2-7 2.5.0-2 ii libpango-1.0-0 1.51.0+ds-3 ii libpangocairo-1.0-0 1.51.0+ds-3 ii libpoppler-glib8 22.12.0-2+b1 ii libraw23 0.21.1-7 ii libstdc++6 13.2.0-6 ii libtiff6 4.5.1+git230720-1 ii sensible-utils 0.0.20 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.4.7-1 ii exiftran 2.10-5 ii exiv20.27.6-1 ii imagemagick 8:6.9.12.98+dfsg1-4 ii imagemagick-6.q16 [imagemagick] 8:6.9.12.98+dfsg1-4 ii librsvg2-common 2.54.7+dfsg-2 ii zenity 3.44.2-1 Versions of packages geeqie suggests: ii gimp 2.10.36-1 pn libjpeg-progs pn xpaint -- no debconf information
Bug#1055067: isc-dhcp-client: network-manager 1.44.2-3 changed path to nm-dhcp-helper, apparmor need update
Package: isc-dhcp-client Version: 4.4.3-P1-4 Followup-For: Bug #1055067 I can confirm this, after a recent upgrade I lost network connectivity and it took some digging to determine the cause. Using dhclient with NetworkManager is probably not uncommon (especially since it's NetworkManager's default behaviour if dhclient is installed), so this should probably be fixed soon so that other people don't suddenly lose their network as well. Cheers, Jan -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages isc-dhcp-client depends on: ii debianutils 5.14 ii iproute2 6.6.0-1 ii libc6 2.37-12 Versions of packages isc-dhcp-client recommends: ii isc-dhcp-common 4.4.3-P1-4 Versions of packages isc-dhcp-client suggests: ii avahi-autoipd 0.8-13 pn isc-dhcp-client-ddns ii systemd-resolved [resolvconf] 255~rc2-2 -- Configuration Files: /etc/apparmor.d/sbin.dhclient changed [not included] -- no debconf information
Bug#1056294: RFS: xsnow/1:3.7.6-1 -- brings Christmas to your desktop
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xsnow": * Package name : xsnow Version : 1:3.7.6-1 Upstream contact : Willem Vermin * URL : https://sourceforge.net/projects/xsnow/ * License : GPL-3+ * Vcs : [fill in URL of packaging vcs] Section : games The source builds the following binary packages: xsnow - brings Christmas to your desktop To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xsnow/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xsnow/xsnow_3.7.6-1.dsc Changes since the last upload: xsnow (1:3.7.6-1) unstable; urgency=low . * New upstream release * Changed Standards Version to 4.6.2 The current sponsor is Adam Borowski, but he is not able to take care of it in the near future. Regards, Willem Vermin
Bug#1056293: gettext: msgfmt --java2 does not support Java 21
Package: gettext Version: 0.21-13 Severity: important Tags: ftbfs sid trixie User: debian-j...@lists.debian.org Usertags: default-java21 X-Debbugs-Cc: vladimir.pe...@canonical.com Dear Maintainer, When building 'ssl-utils-clojure' package with Java 21 as default, the build fails with the following trace: -- Applying task i18n to [make] Running 'make i18n' make[1]: *** [debian/rules:19: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:12: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Running make in the build chroot produces the following error: --- msgfmt --java2 -d resources -r puppetlabs.ssl_utils.Messages -l eo locales/eo.po msgfmt: Java compiler not found, try installing gcj or set $JAVAC msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC make: *** [dev-resources/Makefile.i18n:94: resources/puppetlabs/ssl_utils/Messages_eo.class] Error 1 --- It appears that gettext package does not support Java 21. Best Regards, Vladimir. -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-10-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gettext depends on: ii gettext-base 0.21-13 ii libc6 2.38-1ubuntu6 ii libgomp1 13.2.0-4ubuntu3 ii libunistring2 1.0-2 ii libxml22.9.14+dfsg-1.3 Versions of packages gettext recommends: ii curl 8.2.1-1ubuntu3.1 ii wget 1.21.3-1ubuntu1 Versions of packages gettext suggests: ii autopoint 0.21-13 pn gettext-doc pn libasprintf-dev pn libgettextpo-dev
Bug#1052574: geotranz: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Dear Maintainers, Would it be possible to consider the attached debdiff as a fix for this issue? Testing done: - build in sid chroot - build in sid chroot with default Java 21 Thank you for considering this patch!!! Best Regards, Vladimir. geotranz_1052574.debdiff Description: Binary data
Bug#1054125: dh-builtusing: Please backport dh-builtusing to bookworm
Hi Nicolas, On Sat, Nov 18, 2023 at 06:27:42PM +0100, Nicolas Boulenguez wrote: > Have you seen this? > https://lists.debian.org/debian-devel/2023/08/ What exactly are you referring to? That's the whole month's archive :) Yes I do read d-devel so I've likely seen whatever you're pointing to :p > > I've been toying with the idea of setting up a Debian-wide system to nag > > maintainers about out-of-date, inconsistent or plain broken packaging git > > repos. This logic to diff the dsc against one built from unstable could be > > part of that effort. > > Some will probably argue that you are trying to influence their > priorities, that non-git .dsc formats are obsolete, and so on. And that's a bad thing because ... ? There's a huge difference between nudging and forcing :) > Moreover, even if you guess the git tag and whether patches are > applied, there is probably no deterministic way to tell if .gitignore > matches the workflow of upstream, Debian or both. Sounds like a job for a new config option in debian/source/ or similar, this is conceptually no different than lintian false-positives. As long as there's a way to override I don't see a problem. > For the avoidance of doubt, I would appreciate such alerts, a Debian > policy about tags and patches, and that .gitignore is only allowed for > self defense... I for sure don't have all this thought yet, I'm happy to collaborate on designing this system if you're interested. BTW: are you at ccc congress? > > Even with git what may be missing is a hook in dpkg-buildpackage to abort > > the (source) build when the worktree is unclean, > > I often build with manual changes in debian/ that I want tested before > committed. Right yeah same. So that wouldn't really help. gbp's --git-ignore-new is already annoying me enough :) > The script I am using is too lazy for public exposure. You can always send me those shameful scripts directly, I don't judge.sh. > Here are the parts unrelated with pbuilder. > > # After a successful build, clean and compare the source directory > # with the contents extracted by dpkg-source. > # The diff must match debian/clean.diff if it exists, else be empty. > # Example: > # Only in ../dsc: Makefile.in > # Only in ../dsc: config.h > # Only in ../dsc: configure > # If lots of files are removed, repackaging with Files-Excluded is > # probably a better option, see uscan(1). > > #!/bin/sh > set -Ceux > > source=$(dpkg-parsechangelog -SSource) > version=$(dpkg-parsechangelog -SVersion) > dsc_dir=../dsc > > debian/rules clean > dpkg-source -x ../$source_$version.dsc $dsc_dir > if ! (diff -qr $dsc_dir . || true) | diff -N debian/clean.diff -; then > # Display a full diagnostic while $dsc_dir is available. > diff -ru $dsc_dir . || true > # When -ru is empty, -N above already reported the obsolete clean.diff. > fi > rm -fr $dsc_dir I see, this is actually really clever. I don't see why we couldn't do this diff on the buildds to get reporting for this Debian wide. I've been meaning to give sbuild some love anyhow. --Daniel signature.asc Description: PGP signature
Bug#1056145: e2fsprogs: FTBFS on hurd-i386
tag 1056145 pending thanks On Fri, Nov 17, 2023 at 07:09:27PM +0100, Svante Signell wrote: > Source: e2fsprogs > Version: 1.47.0-2 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > X-Debbugs-CC: debian-h...@lists.debian.org > > I chose to submit this patch to Debian instead of upstream as recommended. The > upstream reports seemed to be a little dated: > https://sourceforge.net/projects/e2fsprogs/ However, that page has the latest > version available for download. The upstream git repo is at https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git and most discussions happen on the linux-ext4 kernel mailing list on vger.kernel.org. I don't really use sourceforge for much besides uploading the release tarballs mostly for old time's sake. But that's fine, becuase in addition to being the Debian maintainer for e2fsprogs, I'malso the upstream maintainer. :-) > Regarding the patch it is a very simple ifdef solution to that specific file. > As > can be found in other parts of the code similar definitions are made. Maybe a > common header file defining PATH_MAX would be a better solution. (or > dynamically > allocating space for strings as is recommended for GNU/Hurd) We don't have a common header file which includes limit.h, which is what brings in PATH_MAX. And the library interfaces are set up much like gethostname, where the caller allocates the buffer and passes in a length. So we'll just do what we've done in other places, and what most other programs do that seem to deal with Hurd's lack of PATH_MAX. Unlike your patch, though, we'll put the #ifndef PATH_MAX at the beginning of file, after the header files are included. - Ted commit 795dcc264f48098ca5b214bba7d1b94189b2e491 Author: Theodore Ts'o Date: Sun Nov 19 21:06:12 2023 -0500 tune2fs.c: define PATH_MAX if it is not defined by the system headers This is needed to compile on GNU/Hurd. Addresses-Debian-Bug: #1056145 Signed-off-by: Theodore Ts'o diff --git a/misc/tune2fs.c b/misc/tune2fs.c index 458f7cf6a..9ffe0d199 100644 --- a/misc/tune2fs.c +++ b/misc/tune2fs.c @@ -51,11 +51,15 @@ extern int optind; #include #include #include -#include +#include /* for PATH_MAX */ #ifdef HAVE_SYS_IOCTL_H #include #endif +#ifndef PATH_MAX +#define PATH_MAX 4096 +#endif + #include "ext2fs/ext2_fs.h" #include "ext2fs/ext2fs.h" #include "ext2fs/kernel-jbd.h"
Bug#1052589: Additional information
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/xml-commons-external/-/merge_requests/1
Bug#1052589: Additional information
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Note: alternatively a new upstream release (M27) does not have this problem. Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/apache-directory-server/-/merge_requests/1
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Mon, Nov 20, 2023 at 12:05:46AM +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: > > Hi Adrian, Hi Hilmar, > > A proper fix would be either to: > > 1. patch the version check out of texlive-bin (preferred), or > > > Did so, see [1]. I did not remove the check completely, I just un-tightened > the version. I can confirm that a texlive package linked on testing (zlib > 1.2.x) is installable on unstable (zlib 1.3.x). I hope this solves the issue > for the next 20 years. I intend to upload new packages tomorrow, this NMU > bug can be closed, once this has been done. > > I just noticed that we had this issue already 13 years ago. [2] And from then zlib1g still has the Breaks: texlive-binaries (<< 2009-12) that will also require updating again. Is there any reason why the check exists at all? If the only effect is breakage every 10-20 years, then it's wrong to keep it. This check would make sense if zlib would make buggy changes where the ABI changes without chaning the library soname, but that is not supposed to happen and if it would happen with a library as widely used as zlib then so much would break in unstable that the revert would be instant. > Hilmar >... cu Adrian
Bug#1039271: mumble: ships sysv-init script without systemd unit
Greetings. I'll to try to incorporate the upstream .service file if possible.b The issue I keep running into with .service files with mumble-server is that I'm not able to get the daemon to start with systemd with most of the .service files I've seen and tried for it so far. Had worked out a working .service file for mumble-server many moons ago as part of another bug report, but I haven't been able to find that work I did again in order to incorporate that. Lack of being able to work out a working .service file is also what has led to delay in releasing Mumble 1.5.517 which I've had a package mostly ready for release since February. :-( Thanks for finding the upstream mumble 1.3.4 service file, I hope that will work in the test VM I have for it. -- Chris On 11/12/23 07:59, Chris Hofstaedtler wrote: Control: reassign -1 mumble-server Hi, * bl...@debian.org : Package: mumble Severity: important Usertags: missing-systemd-service [..] mumble has been flagged by Lintian as shipping a sysv-init script without a corresponding systemd unit file. The default init system in Debian is systemd, and so far this worked because a transitional sysv-init-to-unit generator was shipped by systemd. This is in the process of being deprecated and will be removed by the time Trixie ships, so the remaining packages that ship init scripts without systemd units will stop working. Upstream actually includes a .service file in the source tree, as can be seen here: https://sources.debian.org/src/mumble/1.3.4-4/scripts/murmur.service/ It seems like installing it with a small patch for the Debian path derivation should hopefully do the job. Best, Chris
Bug#1056279: Looks like the systemctl links are gone but not the pm-utils ones
Control: tags -1 + confirmed Control: clone -1 -2 Control: reassign -2 systemd-sysv Control: found -2 255-rc2-1 Control: retitle -2 duplicated diversions are still broken by moved files On Sun, Nov 19, 2023 at 02:08:35PM -0800, Francois Marier wrote: > I'm also a little confused by the diverts. Perhaps something changed in > systemd (which owns the ultimate underlying symlinks)? I was sure I had this properly tested and yet it doesn't work as expected. I'm sorry for having gotten this wrong. Reproducer: mmdebstrap bookworm /dev/null http://deb.debian.org/debian --include=systemd-sysv,molly-guard --customize-hook='sed -i -e s/bookworm/sid/ $1/etc/apt/sources.list' --chrooted-customize-hook='apt-get update' --chrooted-customize-hook='apt-get -y install systemd-sysv' --customize-hook='ls -l $1/lib/molly-guard/' Different reproducer: mmdebstrap trixie /dev/null http://deb.debian.org/debian --include=systemd-sysv,molly-guard --customize-hook='sed -i -e s/trixie/sid/ $1/etc/apt/sources.list' --chrooted-customize-hook='apt-get update' --customize-hook='test -e $1/lib/molly-guard/reboot' --chrooted-customize-hook='apt-get -y install systemd-sysv' --customize-hook='ls -l $1/lib/molly-guard/' Specifically, the files vanish on upgrading systemd-sysv such that /sbin/reboot moves to /usr/sbin/reboot. I should have seen this failure in earlier tests. I've dug into dpkg and usually when it moves a file from / to /usr, it'll first unpack the new file (unknowingly replacing the existing old one) and then removes the old one (via pkg_remove_old_files). During that removal, it has a check to see whether the file to be removed happens to match one of the files it just installed and skips the removal in that case. For some reason, this safety check does not work when the file is diverted. So I have a vague understanding of what is wrong here, but no solution yet. For the time being, I duplicate this into a blocker bug for systemd-sysv to prevent it from migrating to testing until we figure out a solution. Sorry for the inconvenience. Helmut
Bug#1055919: python-ansible-pygments: please make the build reproducible
Control: clone 1055919 -1
Control: reassign -1 dh-python 5.20230130+deb12u1
Making a clone of this bug for dh-python to track it getting fixed
there; MR to come.
Context:
On Thu, 16 Nov 2023 17:33:58 +1100 Stuart Prescott
wrote:
> tldr: smells like a dh-python bug - I'll look at it more and reassign
> etc later.
>
>
> Staring at some build logs some more:
>
> * the dirs are generated always
> * they get copied from .../.pybuild to ../debian/$package/ always
> * they are supposed to get removed by dh_python3
> * that removal is not always working
>
> A common theme of the failures is that there are _two_
> /usr/lib/python3.11/dist-packages/.foo directories to remove and only
> one of them is being removed. For python-ansible-pygments, .pytest_cache
> was being removed by dh-python3 but .test-results was not.
>
> Adding in PYBUILD_VERBOSE=1 and some breakpoints into dh-python
> (specifically /usr/share/dh-python/dhpython/fs.py), I think there's a
> subtle bug about altering `dirs` while inside a loop from `os.walk`:
>
> for name in dirs:
> if name in ('test', 'tests') or name.startswith('.'):
> log.debug('removing dist-packages/%s', name)
> rmtree(join(root, name))
> dirs.remove(name)
>
> Removing `name` from `dirs` means that the next item is accidentally
> skipped. A classic "don't change the object you're iterating through
> while you are iterating through it" issue:
>
> In [1]: L = list(range(0, 10))
>
> In [2]: for i in L:
> ...: print(i)
> ...: L.remove(i)
> ...:
> 0
> 2
> 4
> 6
> 8
>
> Which item is not processed in the next iteration by dh_python3 now
> depends on the order in which `os.walk` lists the directories. That is
> presumably dependent on all manner of things (filesystem? collation?
> luck?). On the r-b setup and building by hand I get different results to
> within sbuild (and on the buildd).
>
> In sbuild on ext4, `find -type d` (I have memory that this reflects disk
> order?) has an order in
> ./debian/python3-ansible-pygments/usr/lib/python3.11/dist-packages of:
>
> .test-results ansible_pygments .pytest_cache
>
> while building by hand on tmpfs, I get
>
> ansible_pygments .test-results .pytest_cache
>
> For the former, accidentally skipping the directory after the one that
> gets removed isn't an issue, but for the latter it is.
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 11/19/23 00:40, Adrian Bunk wrote: Hi Adrian, A proper fix would be either to: 1. patch the version check out of texlive-bin (preferred), or Did so, see [1]. I did not remove the check completely, I just un-tightened the version. I can confirm that a texlive package linked on testing (zlib 1.2.x) is installable on unstable (zlib 1.3.x). I hope this solves the issue for the next 20 years. I intend to upload new packages tomorrow, this NMU bug can be closed, once this has been done. I just noticed that we had this issue already 13 years ago. [2] Hilmar [1] https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/untighten_version_check_zlib.diff [2] https://lists.debian.org/debian-tex-maint/2010/06/msg00071.html -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056290: systemd-homed should require libnss-systemd
Package: systemd-homed Version: 254.5-1~bpo12+2 Severity: normal Hello, I recently tried to manage a local user account through systemd-homed, and noticed that it isn't operable without libnss-systemd and the associated changes to /etc/nsswitch.conf, as mentioned in the nss-systemd(8) man page. I would probably be useful to always have libnss-systemd installed together with systemd-homed. Alex. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.0-rpi6-rpi-v8 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-homed depends on: ii init-system-helpers 1.65.2 ii libblkid12.38.1-5+b1 ii libc62.36-9+rpt2+deb12u3 ii libcap2 1:2.66-4 ii libfdisk12.38.1-5+b1 ii libp11-kit0 0.24.1-2 ii libpam-runtime 1.5.2-6+rpt2+deb12u1 ii libpam0g 1.5.2-6+rpt2+deb12u1 ii libssl3 3.0.11-1~deb12u2+rpt1 ii libsystemd-shared254.5-1~bpo12+2 ii systemd 254.5-1~bpo12+2 ii systemd-userdbd 254.5-1~bpo12+2 systemd-homed recommends no packages. systemd-homed suggests no packages. -- no debconf information
Bug#1056289: Clarification of error message in u-boot-install-sunxi
Package: u-boot-sunxi
Version: 2023.07+dfsg-1
Severity: normal
Tags: patch
Hi Vagrant,
When u-boot-install-sunxi does not recognise the system model name, it
prints the following error message:
ERROR: Unknown system: (...)
Specify target: TARGET=/usr/lib/u-boot/UBOOT
I think it might not be clear to everyone what "UBOOT" means here, so
I suggest "/" instead. The patch is below.
(This is the last of the minor changes suggested in bug#979688 that I
meant to file separate bug reports for.)
Thanks very much,
Harold.
diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index b3af2c0b80..f3732ce326 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -50,7 +50,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
"Xunlong Orange Pi Zero")
TARGET="/usr/lib/u-boot/orangepi_zero" ;;
*)
echo >&2 "ERROR: Unknown system: ${dtmodelname}"
- echo >&2 "Specify target: TARGET=/usr/lib/u-boot/UBOOT"
+ echo >&2 "Specify target:
TARGET=/usr/lib/u-boot//"
exit 1
;;
esac
Bug#1056166: systemd-homed: `passwd` fails
Package: systemd-homed Version: 254.5-1~bpo12+2 Followup-For: Bug #1056166 Hello, I can confirm this problem still exists in bookworm and bookworm-backports: As soon as the Debian systemd-homed PAM configuration is activated by pam-auth-update, it's not possible to change passwords of users that come from /etc/passwd anymore. This seems to be due to a PAM misconfiguration. I don't understand enough of the Debian PAM setup to say why it doesn't work, but I tried replacing the rules with alternatives that I copied from an openSUSE Tumbleweed install, and using those it's possible to change details on users both from /etc/passwd and systemd-homed. Alex. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.0-rpi6-rpi-v8 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-homed depends on: ii init-system-helpers 1.65.2 ii libblkid12.38.1-5+b1 ii libc62.36-9+rpt2+deb12u3 ii libcap2 1:2.66-4 ii libfdisk12.38.1-5+b1 ii libp11-kit0 0.24.1-2 ii libpam-runtime 1.5.2-6+rpt2+deb12u1 ii libpam0g 1.5.2-6+rpt2+deb12u1 ii libssl3 3.0.11-1~deb12u2+rpt1 ii libsystemd-shared254.5-1~bpo12+2 ii systemd 254.5-1~bpo12+2 ii systemd-userdbd 254.5-1~bpo12+2 systemd-homed recommends no packages. systemd-homed suggests no packages. -- no debconf information
Bug#1056288: django-assets FTBFS: TypeError: 'TextNode' object is not iterable
Source: django-assets Version: 2.0-3 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=django-assets=all=2.0-3=1700432008=0 ... dh_auto_test -i -O--buildsystem=pybuild I: pybuild base:310: cd /<>/.pybuild/cpython3_3.11_django-assets/build; python3.11 -m nose -v tests tests.test_django.TestConfig.test_custom_options ... ok The builtin options have different names within the Django ... ok tests.test_django.TestFilter.test_template ... ok tests.test_django.TestLoader.test ... ERROR tests.test_django.TestLoader.test_cached_loader ... ERROR Finders are used to find source files. ... ok If debug is disabled, the finders are not used. ... ok Test that the cssrewrite filter can deal with staticfiles. ... ok Globs can be used across staticdirs. ... ok Recursive globs. ... ok An error is raised if a source file is missing. ... ok The files we write to STATIC_ROOT are served in debug mode ... ok tests.test_django.TestTemplateTag.test_debug_option ... ok Ensure the tag correcly spits out the urls the bundle returns. ... ok tests.test_django.TestTemplateTag.test_reference_bundles ... ok tests.test_django.TestTemplateTag.test_reference_files ... ok tests.test_django.TestTemplateTag.test_reference_mixed ... ok Using commas is optional. ... ok tests.test_django.TestTemplateTag.test_with_vars ... ok == ERROR: tests.test_django.TestLoader.test -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/<>/.pybuild/cpython3_3.11_django-assets/build/tests/test_django.py", line 193, in test bundles = self.loader.load_bundles() ^^ File "/<>/.pybuild/cpython3_3.11_django-assets/build/django_assets/loaders.py", line 79, in load_bundles bundles.extend(self.with_file(filename, self._parse) or []) ^ File "/usr/lib/python3/dist-packages/webassets/loaders.py", line 333, in with_file return then_run(filename, contents) File "/<>/.pybuild/cpython3_3.11_django-assets/build/django_assets/loaders.py", line 110, in _parse for node in t: # don't move into _recurse_node, ``Template`` has a .nodelist attribute File "/usr/lib/python3/dist-packages/django/template/base.py", line 158, in __iter__ yield from node TypeError: 'TextNode' object is not iterable == ERROR: tests.test_django.TestLoader.test_cached_loader -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/<>/.pybuild/cpython3_3.11_django-assets/build/tests/test_django.py", line 203, in test_cached_loader bundles = self.loader.load_bundles() ^^ File "/<>/.pybuild/cpython3_3.11_django-assets/build/django_assets/loaders.py", line 79, in load_bundles bundles.extend(self.with_file(filename, self._parse) or []) ^ File "/usr/lib/python3/dist-packages/webassets/loaders.py", line 333, in with_file return then_run(filename, contents) File "/<>/.pybuild/cpython3_3.11_django-assets/build/django_assets/loaders.py", line 110, in _parse for node in t: # don't move into _recurse_node, ``Template`` has a .nodelist attribute File "/usr/lib/python3/dist-packages/django/template/base.py", line 158, in __iter__ yield from node TypeError: 'TextNode' object is not iterable -- Ran 19 tests in 0.113s FAILED (errors=2)
Bug#1053700: xarray test failure on s390x
Control: tags -1 patch
These all come from xarray/tests/test_coding_times.py, and are probably
fixable by replacing both instances of ("M8[ns]" if
sys.byteorder=='big' else "haven't actually tried that.
Bug#1056279: Looks like the systemctl links are gone but not the pm-utils ones
CCing Helmut who wrote the initial patch for systemd 255+ support (see Bug#1055510). I also see the same thing: $ ls -lh /usr/lib/molly-guard/ Permissions Size User Group Date Modified Name .rwxr-xr-x 3,4k root root 11 nov 14:02 molly-guard* lrwxrwxrwx31 root root 14 nov 2019 pm-hibernate -> /usr/lib/pm-utils/bin/pm-action* lrwxrwxrwx31 root root 14 nov 2019 pm-suspend -> /usr/lib/pm-utils/bin/pm-action* lrwxrwxrwx31 root root 14 nov 2019 pm-suspend-hybrid -> /usr/lib/pm-utils/bin/pm-action* $ sudo reboot --help E: not a regular file: /usr/lib/molly-guard/reboot I'm also a little confused by the diverts. Perhaps something changed in systemd (which owns the ultimate underlying symlinks)? Francois -- https://fmarier.org/
Bug#1050854: xarray test failure on amd64
This bug is now a crash (not the original error message): https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/39962554/log.gz I don't know whether the same patch still works. The Salsa repository now appears to be up to date. You probably also want to include the fixes for the other two RC bugs (see there).
Bug#1056287: adios2: binary-all FTBFS
Source: adios2 Version: 2.8.2+dfsg1-2 Severity: serious Tags: ftbfs X-Debbugs-Cc: Drew Parsons https://buildd.debian.org/status/fetch.php?pkg=adios2=all=2.8.2%2Bdfsg1-2=1700402832=0 ... debian/rules override_dh_missing make[1]: Entering directory '/<>' dh_missing --sourcedir=install-serial dh_missing: warning: usr/bin/adios2-config.serial exists in install-serial but is not installed to anywhere dh_missing: error: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_cmake_install: adios2-data (13), adios2-mpi-bin (7), adios2-scripts (14), adios2-serial-bin (4), libadios2-mpi-c++11-2 (4), libadios2-mpi-c++11-dev (16), libadios2-mpi-c-2 (4), libadios2-mpi-c-dev (12), libadios2-mpi-core-2 (5), libadios2-mpi-core-dev (184), libadios2-mpi-fortran-2 (4), libadios2-mpi-fortran-dev (33), libadios2-serial-c++11-2 (2), libadios2-serial-c++11-dev (15), libadios2-serial-c-2 (2), libadios2-serial-c-dev (11), libadios2-serial-core-2 (3), libadios2-serial-core-dev (183), libadios2-serial-fortran-2 (2), libadios2-serial-fortran-dev (30), python3-adios2-mpi (1), python3-adios2-serial (1) * dh_install: adios2-data (0), adios2-mpi-bin (0), adios2-scripts (0), adios2-serial-bin (0), libadios2-common-c++11-dev (0), libadios2-common-c-dev (0), libadios2-common-core-dev (0), libadios2-mpi-auxiliary-2 (10), libadios2-mpi-auxiliary-dev (6), libadios2-mpi-c++11-2 (0), libadios2-mpi-c++11-dev (0), libadios2-mpi-c-2 (0), libadios2-mpi-c-dev (0), libadios2-mpi-core-2 (0), libadios2-mpi-core-dev (0), libadios2-mpi-fortran-2 (0), libadios2-mpi-fortran-dev (0), libadios2-serial-auxiliary-2 (10), libadios2-serial-auxiliary-dev (6), libadios2-serial-c++11-2 (0), libadios2-serial-c++11-dev (0), libadios2-serial-c-2 (0), libadios2-serial-c-dev (0), libadios2-serial-core-2 (0), libadios2-serial-core-dev (0), libadios2-serial-fortran-2 (0), libadios2-serial-fortran-dev (0), python3-adios2 (1), python3-adios2-mpi (0), python3-adios2-serial (0) * dh_installdocs: adios2-data (0), adios2-mpi-bin (0), adios2-scripts (0), adios2-serial-bin (0), libadios2-common-c++11-dev (0), libadios2-common-c-dev (0), libadios2-common-core-dev (0), libadios2-mpi-auxiliary-2 (0), libadios2-mpi-auxiliary-dev (0), libadios2-mpi-c++11-2 (0), libadios2-mpi-c++11-dev (0), libadios2-mpi-c-2 (0), libadios2-mpi-c-dev (0), libadios2-mpi-core-2 (0), libadios2-mpi-core-dev (0), libadios2-mpi-fortran-2 (0), libadios2-mpi-fortran-dev (0), libadios2-serial-auxiliary-2 (0), libadios2-serial-auxiliary-dev (0), libadios2-serial-c++11-2 (0), libadios2-serial-c++11-dev (0), libadios2-serial-c-2 (0), libadios2-serial-c-dev (0), libadios2-serial-core-2 (0), libadios2-serial-core-dev (0), libadios2-serial-fortran-2 (0), libadios2-serial-fortran-dev (0), python3-adios2 (1), python3-adios2-mpi (0), python3-adios2-serial (0) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. make[1]: *** [debian/rules:172: override_dh_missing] Error 25
Bug#1044869: xarray test failure on i386
Control: tags -1 patch This patch has been probably-by-accident dropped again, and hence this bug has reappeared again: https://ci.debian.net/data/autopkgtest/testing/i386/p/python-xarray/39962705/log.gz Re-adding it would probably work, but I haven't actually tried that.
Bug#1056286: node-get-stream: FTBFS in sid with internet access disabled
Package: node-get-stream
Version: 8.0.1-8
Severity: serious
Tags: patch
Hello,
looks like the package is using internet during tests, and so FTBFS without
internet access.
The log is:
✔ string › handles truncated UTF-8 sequences over maxBuffer
✔ string › get stream with invalid UTF-8 sequences
─
integration › works with fetch()
Rejected promise returned by test. Reason:
TypeError {
cause: Error {
code: 'ENOTFOUND',
errno: -3008,
hostname: 'nodejs.org',
syscall: 'getaddrinfo',
message: 'getaddrinfo ENOTFOUND nodejs.org',
},
message: 'fetch failed',
}
› async file://test/integration.js:66:18
─
1 test failed
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
Can you please have a look?
thanks
G.
Bug#1052586: Additional information
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/debian-astro-team/aladin/-/merge_requests/1
Bug#1052551: gnome-calculator: Does not start from GUI (gnome), incurs error: "Calculator is not responding force quit wait"
This is caused by this issue: https://gitlab.gnome.org/GNOME/gnome-calculator/-/issues/359 Basically, if the calculator can't get the new exchange rate data (possibly because of a VPN) it won't run. The workaround is to turn off Wi-Fi, run gnome-calculator, click on the hamburger menu in the upper right corner, click "Preferences", and then change the "Exchange rate refresh interval" to "Never". Then the calculator will run, even with Wi-Fi turned back on. It just won't update the exchange rate. -- ethical_haquer Sent with [Proton Mail](https://proton.me/) secure email.
Bug#1056160: ITS: auctex
> PH == Preuße, Hilmar [2023-11-19] [...] PH> Actually it is #1056210 and friends. Hi Hilmar, I see, thanks. I should wait for a solution to #1056204 before uploading. -- Thanks, Davide
Bug#1052583: com-hypirion-io-clojure: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/clojure-team/com-hypirion-io-clojure/-/merge_requests/2
Bug#1052582: nescc: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/debian/nescc/-/merge_requests/1#9c96da0e9f91d7d8937b69b524702c106258f0d1
Bug#1039533: Offer a way to just print the numbers, not also the units
I added an example to the --terse entry in the manual. Debian should close this bug. On Thu, Jun 29, 2023 at 07:55:59AM -0500, Dan Jacobson wrote: > Ah ha! > You see the batch job user scours the man page, and only finds: > > >-1, --one-line > Give only one line of output (the forward conversion); do not > print the reverse conversion. If a reciprocal conversion is > performed, then units will still print the “reciprocal conver‐ > sion” line. > >-t, --terse > Print only a single conversion factor. This option can be used > when calling units from another program so that the output is > easy to parse. This option has the combined effect of these op‐ > tions: ‘--strict’ ‘--quiet’ ‘--one-line’ ‘--compact’. When > combined with ‘--version’ it produces a display showing only the > program name and version number. > >--compact > Give compact output featuring only the conversion factor; the > multiplication and division signs are not shown, and there is no > leading whitespace. If you convert to a unit list, then the > output is a semicolon separated list of factors. This turns off > the ‘--verbose’ option. > > But in fact, --terse should say: > >-t, --terse > Print only a single conversion factor. This option can be used > when calling units from another program so that the output is > easy to parse. This option has the combined effect of these op‐ > tions: ‘--strict’ ‘--quiet’ ‘--one-line’ ‘--compact’. When > combined with ‘--version’ it produces a display showing only the > program name and version number. And here we even strip > the units off: > > $ units --terse mile meters > 1609.344 > > I am saying that people who are looking to strip things down... their > eyes will focus on that part of the man page, so be sure to repeat that > feature there. > > So indeed, there is no need for things like, > > $ dlocate --help > -f, --filename-only Strip 'package: ' prefix from search output > -p, --package-only Output package names only when searching > > because units already has what it needs. It just needs to mention it on > the right spot on the man page again. Thanks.
Bug#1056280: audacity: Welcome dialog show/hide text is not visible when Desktop Environment (DE) is in dark mode.
Control: forwarded 1056280 https://github.com/audacity/audacity/issues/2024 Upstream bug. Seems like upstream are reluctant to fix. Regards Phil -- Playing the game for the games sake. * Debian Maintainer Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org Social: * Instagram: kathenasorg * Threads: @kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1056285: RFS: opendkim/2.11.0~beta2-9 -- DomainKeys Identified Mail (DKIM) signing and verifying milter
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opendkim": * Package name : opendkim Version : 2.11.0~beta2-9 Upstream contact : The Trusted Domain Project * URL : http://www.opendkim.org/ * License : BSD-3-clause and SOSL, ISC, GPL-3+ with AutoConf exception * Vcs : https://salsa.debian.org/debian/opendkim Section : mail The source builds the following binary packages: opendkim - DomainKeys Identified Mail (DKIM) signing and verifying milter opendkim-tools - utilities for administering the OpenDKIM milter libopendkim11 - DomainKeys Identified Mail (DKIM) library libopendkim-dev - DomainKeys Identified Mail (DKIM) library (development files) libvbr2 - Vouch By Reference (VBR) library libvbr-dev - Vouch By Reference (VBR) library (development files) librbl1 - Real-time Blacklist (RBL) query library librbl-dev - Real-time Blacklist (RBL) query library (development files) miltertest - utility for testing milter applications To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opendkim/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-9.dsc Changes since the last upload: opendkim (2.11.0~beta2-9) unstable; urgency=medium . [ David Bürgin ] * debian/patches: Add missing upstream bug metadata, add new patches: - rev-ares-deletion.patch: Delete Authentication-Results headers in reverse, addresses CVE-2022-48521 (Closes: #1041107). - ares-missing-space.patch: Add missing space in Auth-Results header. * Replace transitional libldap2-dev with libldap-dev in Build-Depends. * Remove obsolete lsb-base dependency in opendkim package. * Delete obsolete entries in debian/opendkim.NEWS. . [ Samuel Thibault ] * d/rules: Generalize hurd-i386 into hurd. Thank you. -- David
Bug#1052581: libmatthew-java: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/debian-iot-team/libmatthew-java/-/merge_requests/4
Bug#1052580: swi-prolog: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/debian/swi-prolog/-/merge_requests/3
Bug#1056153: 6.1.0-0.deb11.9-amd64: Linux version 6.1.0-0.deb11.9-amd64 booting to black screen, but 6.1.0-0.deb11.7-amd64 works
Source: linux Source-Version: 1056153 Hi, On Sun, Nov 19, 2023 at 07:48:42PM +0100, Debian bugs wrote: > Hi Salvatore, > > Great! > I installed linux-image-6.1.0-0.deb11.13-amd64-unsigned > With kernel 6.1.55 it is booting again. Thanks for confirming! Regards, Salvatore
Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
On Sat, 18 Nov 2023, Cyril Brulebois wrote: Scott Talbert (2023-11-16): Scott Talbert (2023-11-13): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)" This looks like a redux of #1054146, with libwx-perl also needing a binNMU (after the libalien-wxwidgets-perl one)? Yeah, I did at least file both at the same time this round though :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908 I was trying to suggest filing both in the same request, to have them scheduled in one go. I tried to figure out how to do that with reportbug, but I did not see an obvious way to do it. For the future, how do I do that? Hand-written bug report? Scott
Bug#1056284: nss: CVE-2023-5388
Source: nss X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for nss. CVE-2023-5388[0]: https://people.redhat.com/~hkario/marvin/ mentions that things were improved in 3.6.1 via CVE-2023-4421, but CVE-2023-5388 was assigned for the remaining issue. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-5388 https://www.cve.org/CVERecord?id=CVE-2023-5388 Please adjust the affected versions in the BTS as needed.
Bug#1056283: postgresql-15: CVE-2023-5868 CVE-2023-5869 CVE-2023-5870
Source: postgresql-15 X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerabilities were published for postgresql-15. CVE-2023-5868[0]: https://www.postgresql.org/support/security/CVE-2023-5868/ https://www.postgresql.org/about/news/postgresql-161-155-1410-1313-1217-and-1122-released-2749/ CVE-2023-5869[1]: https://www.postgresql.org/support/security/CVE-2023-5869/ https://www.postgresql.org/about/news/postgresql-161-155-1410-1313-1217-and-1122-released-2749/ CVE-2023-5870[2]: https://www.postgresql.org/support/security/CVE-2023-5870/ https://www.postgresql.org/about/news/postgresql-161-155-1410-1313-1217-and-1122-released-2749/ If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-5868 https://www.cve.org/CVERecord?id=CVE-2023-5868 [1] https://security-tracker.debian.org/tracker/CVE-2023-5869 https://www.cve.org/CVERecord?id=CVE-2023-5869 [2] https://security-tracker.debian.org/tracker/CVE-2023-5870 https://www.cve.org/CVERecord?id=CVE-2023-5870 Please adjust the affected versions in the BTS as needed.
Bug#1056282: gpac: CVE-2023-47384 CVE-2023-4785 CVE-2023-48011 CVE-2023-48013 CVE-2023-48014 CVE-2023-5998 CVE-2023-46001
Source: gpac X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for gpac. CVE-2023-47384[0]: | MP4Box GPAC v2.3-DEV-rev617-g671976fcc-master was discovered to | contain a memory leak in the function gf_isom_add_chapter at | /isomedia/isom_write.c. This vulnerability allows attackers to cause | a Denial of Service (DoS) via a crafted MP4 file. https://github.com/gpac/gpac/issues/2672 CVE-2023-4785[1]: | Lack of error handling in the TCP server in Google's gRPC starting | version 1.23 on posix-compatible platforms (ex. Linux) allows an | attacker to cause a denial of service by initiating a significant | number of connections with the server. Note that gRPC C++ Python, | and Ruby are affected, but gRPC Java, and Go are NOT affected. https://github.com/grpc/grpc/pull/33656 https://github.com/grpc/grpc/pull/33667 https://github.com/grpc/grpc/pull/33669 https://github.com/grpc/grpc/pull/33670 https://github.com/grpc/grpc/pull/33672 CVE-2023-48011[2]: | GPAC v2.3-DEV-rev566-g50c2ab06f-master was discovered to contain a | heap-use-after-free via the flush_ref_samples function at | /gpac/src/isomedia/movie_fragments.c. https://github.com/gpac/gpac/issues/2611 https://github.com/gpac/gpac/commit/c70f49dda4946d6db6aa55588f6a756b76bd84ea CVE-2023-48013[3]: | GPAC v2.3-DEV-rev566-g50c2ab06f-master was discovered to contain a | double free via the gf_filterpacket_del function at | /gpac/src/filter_core/filter.c. https://github.com/gpac/gpac/issues/2612 https://github.com/gpac/gpac/commit/cd8a95c1efb8f5bfc950b86c2ef77b4c76f6b893 CVE-2023-48014[4]: | GPAC v2.3-DEV-rev566-g50c2ab06f-master was discovered to contain a | stack overflow via the hevc_parse_vps_extension function at | /media_tools/av_parsers.c. https://github.com/gpac/gpac/issues/2613 https://github.com/gpac/gpac/commit/66abf0887c89c29a484d9e65e70882794e9e3a1b CVE-2023-5998[5]: | Out-of-bounds Read in GitHub repository gpac/gpac prior to | 2.3.0-DEV. https://huntr.com/bounties/ea02a231-b688-422b-a881-ef415bcf6113 https://github.com/gpac/gpac/commit/db74835944548fc3bdf03121b0e012373bdebb3e CVE-2023-46001[6]: | Buffer Overflow vulnerability in gpac MP4Box v.2.3-DEV- | rev573-g201320819-master allows a local attacker to cause a denial | of service via the gpac/src/isomedia/isom_read.c:2807:51 function in | gf_isom_get_user_data. https://github.com/gpac/gpac/issues/2629 https://github.com/gpac/gpac/commit/e79b0cf7e72404750630bc01340e999f3940dbc4 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-47384 https://www.cve.org/CVERecord?id=CVE-2023-47384 [1] https://security-tracker.debian.org/tracker/CVE-2023-4785 https://www.cve.org/CVERecord?id=CVE-2023-4785 [2] https://security-tracker.debian.org/tracker/CVE-2023-48011 https://www.cve.org/CVERecord?id=CVE-2023-48011 [3] https://security-tracker.debian.org/tracker/CVE-2023-48013 https://www.cve.org/CVERecord?id=CVE-2023-48013 [4] https://security-tracker.debian.org/tracker/CVE-2023-48014 https://www.cve.org/CVERecord?id=CVE-2023-48014 [5] https://security-tracker.debian.org/tracker/CVE-2023-5998 https://www.cve.org/CVERecord?id=CVE-2023-5998 [6] https://security-tracker.debian.org/tracker/CVE-2023-46001 https://www.cve.org/CVERecord?id=CVE-2023-46001 Please adjust the affected versions in the BTS as needed.
Bug#1056281: snort: CVE-2023-20246 CVE-2023-20031
Source: snort X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for snort. CVE-2023-20246[0]: | Multiple Cisco products are affected by a vulnerability in Snort | access control policies that could allow an unauthenticated, remote | attacker to bypass the configured policies on an affected system. | This vulnerability is due to a logic error that occurs when the | access control policies are being populated. An attacker could | exploit this vulnerability by establishing a connection to an | affected device. A successful exploit could allow the attacker to | bypass configured access control rules on the affected system. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftd-snort3acp-bypass-3bdR2BEh CVE-2023-20031[1]: | A vulnerability in the SSL/TLS certificate handling of Snort 3 | Detection Engine integration with Cisco Firepower Threat Defense | (FTD) Software could allow an unauthenticated, remote attacker to | cause the Snort 3 detection engine to restart. This vulnerability is | due to a logic error that occurs when an SSL/TLS certificate that is | under load is accessed when it is initiating an SSL connection. | Under specific, time-based constraints, an attacker could exploit | this vulnerability by sending a high rate of SSL/TLS connection | requests to be inspected by the Snort 3 detection engine on an | affected device. A successful exploit could allow the attacker to | cause the Snort 3 detection engine to reload, resulting in either a | bypass or a denial of service (DoS) condition, depending on device | configuration. The Snort detection engine will restart | automatically. No manual intervention is required. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftd-snort3-8U4HHxH8 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-20246 https://www.cve.org/CVERecord?id=CVE-2023-20246 [1] https://security-tracker.debian.org/tracker/CVE-2023-20031 https://www.cve.org/CVERecord?id=CVE-2023-20031 Please adjust the affected versions in the BTS as needed.
Bug#1052576: clj-yaml-clojure: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Dear Maintainers, Would it be possible to consider a merge request[1] that adds a patch fixing this bug? Best Regards, Vladimir. [1] https://salsa.debian.org/clojure-team/clj-yaml-clojure/-/merge_requests/1
Bug#1056280: audacity: Welcome dialog show/hide text is not visible when Desktop Environment (DE) is in dark mode.
Package: audacity Version: 3.4.0+dfsg-1 Severity: minor X-Debbugs-Cc: philip.wy...@kathenas.org Dear Maintainer, * Install 'audacity'. * Run 'audacity'. * 'OK' the welcome dialog. * Edit theme to dark on a dark mode Desktop Environment (DE) such as GNOME. * Close 'audacity'. * Restart audacity. The welcome dialog show/hide text will be a very light grey and hardly visible to the user. Regards Phil -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages audacity depends on: ii audacity-data3.4.0+dfsg-1 ii libasound2 1.2.10-1 ii libc62.37-12 ii libexpat12.5.0-2 ii libflac++10 1.4.3+ds-2 ii libflac121.4.3+ds-2 ii libgcc-s113.2.0-6 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libglib2.0-0 2.78.1-4 ii libgtk-3-0 3.24.38-6 ii libid3tag0 0.15.1b-14 ii liblilv-0-0 0.24.22-1 ii libmpg123-0 1.32.3-1 ii libogg0 1.3.5-3 ii libopus0 1.4-1 ii libportaudio219.6.0-1.2 ii libportmidi0 1:217-6.1 ii libportsmf0 0.1~svn20101010-6 ii libsbsms10 2.3.0-1 ii libsndfile1 1.2.2-1 ii libsoundtouch1 2.3.2+ds1-1 ii libsoxr0 0.1.3-4 ii libsqlite3-0 3.44.0-1 ii libstdc++6 13.2.0-6 ii libsuil-0-0 0.10.20-1 ii libtwolame0 0.4.0-2 ii libuuid1 2.39.2-6 ii libvamp-hostsdk3v5 2.10.0-4 ii libvorbis0a 1.3.7-1 ii libvorbisenc21.3.7-1 ii libvorbisfile3 1.3.7-1 ii libwavpack1 5.6.0-1 ii libwxbase3.2-1 3.2.4+dfsg-1 ii libwxgtk3.2-13.2.4+dfsg-1 audacity recommends no packages. Versions of packages audacity suggests: pn ladspa-plugin -- no debconf information
Bug#1056160: ITS: auctex
On 19.11.2023 18:09, Davide G. M. Salvetti wrote: Hi Davide, I have not yet digged into it, but it looks similar to #1051243. What do you think? Actually it is #1056210 and friends. The root cause of #1051243 has been fixed long ago, just the phenomenon looks similar to #1056210, hence people reopen the bug. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056279: Symlinks in /usr/lib/molly-guard/ are gone after upgrade
Christoph Biedl wrote... > after upgrading from 0.7.2 to 0.8.1, the symlinks in /usr/lib/molly-guard/ > are gone. It was suggested in IRC this might be the effect of another package's upgrade. I find that unlikely since no other package should touch /usr/lib/molly-guard/ - still, here's the upgrade list after that I found the change: 2023-11-19 18:50:51 upgrade bsdutils:ppc64 1:2.39.2-5 1:2.39.2-6 2023-11-19 18:50:53 upgrade coreutils:ppc64 9.1-1 9.4-2 2023-11-19 18:50:55 upgrade libsmartcols1:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:50:56 upgrade util-linux-extra:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:50:57 upgrade util-linux:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:51:04 upgrade mount:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:51:05 upgrade systemd-dev:all 254.5-1 255~rc2-2 2023-11-19 18:51:06 upgrade libblkid1:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:51:07 upgrade libuuid1:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:51:08 upgrade libfdisk1:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:51:09 upgrade libmount1:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:51:10 upgrade systemd:ppc64 254.5-1 255~rc2-2 2023-11-19 18:51:13 upgrade libsystemd-shared:ppc64 254.5-1 255~rc2-2 2023-11-19 18:51:14 upgrade libsystemd0:ppc64 254.5-1 255~rc2-2 2023-11-19 18:51:15 upgrade molly-guard:all 0.7.2 0.8.1 Note: The timestamp of /usr/lib/molly-guard/ fits here: drwxr-xr-x 2 root root 4096 2023-11-19 18:52:08.994207913 +0100 /usr/lib/molly-guard/ 2023-11-19 18:52:08 upgrade systemd-sysv:ppc64 254.5-1 255~rc2-2 2023-11-19 18:52:09 upgrade libdb5.3:ppc64 5.3.28+dfsg2-3 5.3.28+dfsg2-4 2023-11-19 18:52:10 upgrade zlib1g:ppc64 1:1.2.13.dfsg-3 1:1.3.dfsg-2 2023-11-19 18:52:12 upgrade libelf1:ppc64 0.189-4 0.190-1 2023-11-19 18:52:13 upgrade libtirpc-common:all 1.3.3+ds-1 1.3.4+ds-1 2023-11-19 18:52:14 upgrade libtirpc3:ppc64 1.3.3+ds-1 1.3.4+ds-1 2023-11-19 18:52:16 upgrade iproute2:ppc64 6.5.0-5 6.6.0-1 2023-11-19 18:52:19 upgrade libgpg-error0:ppc64 1.47-2 1.47-3 2023-11-19 18:52:20 upgrade udev:ppc64 254.5-1 255~rc2-2 2023-11-19 18:52:21 upgrade libudev1:ppc64 254.5-1 255~rc2-2 2023-11-19 18:52:23 upgrade mawk:ppc64 1.3.4.20230808-1 1.3.4.20231102-1 2023-11-19 18:52:23 upgrade fdisk:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:52:24 upgrade vim-nox:ppc64 2:9.0.2087-1 2:9.0.2103-1 2023-11-19 18:52:25 upgrade vim:ppc64 2:9.0.2087-1 2:9.0.2103-1 2023-11-19 18:52:26 upgrade vim-common:all 2:9.0.2087-1 2:9.0.2103-1 2023-11-19 18:52:28 upgrade vim-runtime:all 2:9.0.2087-1 2:9.0.2103-1 2023-11-19 18:52:32 upgrade autopkgtest:all 5.31 5.31.1 2023-11-19 18:52:33 upgrade bsdextrautils:ppc64 2.39.2-5 2.39.2-6 2023-11-19 18:52:35 upgrade libglib2.0-0:ppc64 2.78.1-3 2.78.1-4 2023-11-19 18:52:36 upgrade libio-socket-ssl-perl:all 2.083-1 2.084-1 2023-11-19 18:52:37 upgrade libmaxminddb0:ppc64 1.7.1-1 1.8.0-1 2023-11-19 18:52:38 upgrade libsasl2-modules-db:ppc64 2.1.28+dfsg1-3 2.1.28+dfsg1-4 2023-11-19 18:52:38 upgrade libsasl2-2:ppc64 2.1.28+dfsg1-3 2.1.28+dfsg1-4 2023-11-19 18:52:39 upgrade pci.ids:all 0.0~2023.08.10-1 0.0~2023.09.22-1 Hope this is helpful, Christoph signature.asc Description: PGP signature
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 19 November 2023 at 09:59, Dirk Eddelbuettel wrote: | On 19 November 2023 at 13:49, Graham Inggs wrote: | | We don't believe only touching debian/changelog, or a binNMU, is | | sufficient. We were surprised that your r-cran-lme4 upload did not at | | least include: | | Depends: r-cran-matrix (>= 1.6-2-1) | | Without that relationship, r-cran-lme4 could migrate to testing and be | | installed on users' systems without the corresponding version of | | r-cran-matrix. It is no surprise that the excuses page for lme4 [4] | | is all red, because that is exactly what is being tested. More on | | this to come in my next email. | | I can add that, and probably should have. And I agree with the sentiment in | your other mail that a transition is overkill here. Done in lme4 1.1-35.1-3. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1056279: Symlinks in /usr/lib/molly-guard/ are gone after upgrade
Package: molly-guard Version: 0.8.1 Severity: grave X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de Greetings, after upgrading from 0.7.2 to 0.8.1, the symlinks in /usr/lib/molly-guard/ are gone. As this happened on a second machine today, I reckon it's not a coincidence. Current state: # ls -l /usr/lib/molly-guard/ total 8 -rwxr-xr-x 1 root root 99 5. Okt 00:17 coldreboot -rwxr-xr-x 1 root root 3365 11. Nov 23:02 molly-guard Old state: # ls -l /usr/lib/molly-guard/ total 7 -rwxr-xr-x 1 root root 99 5. Okt 00:17 coldreboot lrwxrwxrwx 1 root root 14 30. Sep 12:34 halt -> /bin/systemctl -rwxr-xr-x 1 root root 2847 9. Jul 2019 molly-guard lrwxrwxrwx 1 root root 14 30. Sep 12:34 poweroff -> /bin/systemctl lrwxrwxrwx 1 root root 14 30. Sep 12:34 reboot -> /bin/systemctl lrwxrwxrwx 1 root root 14 30. Sep 12:34 shutdown -> /bin/systemctl This is the upgrade log: Preparing to unpack .../molly-guard_0.8.1_all.deb ... No diversion 'diversion of /sbin/pm-hibernate by molly-guard', none removed. No diversion 'diversion of /sbin/pm-suspend by molly-guard', none removed. No diversion 'diversion of /sbin/pm-suspend-hybrid by molly-guard', none removed. Adding 'diversion of /usr/sbin/halt to /usr/lib/molly-guard/halt by molly-guard' Leaving 'diversion of /sbin/halt to /lib/molly-guard/halt by molly-guard' Adding 'diversion of /usr/sbin/poweroff to /usr/lib/molly-guard/poweroff by molly-guard' Leaving 'diversion of /sbin/poweroff to /lib/molly-guard/poweroff by molly-guard' Adding 'diversion of /usr/sbin/reboot to /usr/lib/molly-guard/reboot by molly-guard' Leaving 'diversion of /sbin/reboot to /lib/molly-guard/reboot by molly-guard' Adding 'diversion of /usr/sbin/shutdown to /usr/lib/molly-guard/shutdown by molly-guard' Leaving 'diversion of /sbin/shutdown to /lib/molly-guard/shutdown by molly-guard' Adding 'diversion of /usr/sbin/coldreboot to /usr/lib/molly-guard/coldreboot by molly-guard' Leaving 'diversion of /sbin/coldreboot to /lib/molly-guard/coldreboot by molly-guard' Removing 'diversion of /usr/sbin/pm-hibernate to /lib/molly-guard/pm-hibernate by molly-guard' Adding 'diversion of /usr/sbin/pm-hibernate to /usr/lib/molly-guard/pm-hibernate by molly-guard' Removing 'diversion of /usr/sbin/pm-suspend to /lib/molly-guard/pm-suspend by molly-guard' Adding 'diversion of /usr/sbin/pm-suspend to /usr/lib/molly-guard/pm-suspend by molly-guard' Removing 'diversion of /usr/sbin/pm-suspend-hybrid to /lib/molly-guard/pm-suspend-hybrid by molly-guard' Adding 'diversion of /usr/sbin/pm-suspend-hybrid to /usr/lib/molly-guard/pm-suspend-hybrid by molly-guard' Unpacking molly-guard (0.8.1) over (0.7.2) ... dpkg: warning: unable to delete old directory '/lib/molly-guard': Directory not empty Setting up molly-guard (0.8.1) ... The resultat is a major problem, hence the severity: Trying to shut down or reboot just triggers an error: # shutdown -P E: not a regular file: /usr/lib/molly-guard/shutdown (Workaround: Manually restore the links.) Looking into the maintainer scripts, I see some changes were done. Can you please re-check they to the right thing? Regards, Chri- "diversions are a nightmare" stoph signature.asc Description: PGP signature
Bug#1056278: safe-vdash - upcoming rust-crossterm and rust-ratatui updates.
Package: safe-vdash I'm currently in the process of preparing updates for crossterm to 0.27 and ratatui to 0.23. save-vdash's cargo dependencies already allow the new versions (indeed the new versions will allow patches to be dropped) but the Debian dependencies currently do not. After bumping the Debian dependecies I was able to build the package successfully. If you want to do further testing the new versions of crossterm and ratatui are available in experimental. If no problems come to light I intend to upload them to unstable in a week or so.
Bug#1055882: libncurses6: waddnstr() reads n+1 bytes, ought to end at n bytes
On Tue, Nov 14, 2023 at 03:50:31PM +0100, наб wrote: > On Mon, Nov 13, 2023 at 08:13:02PM -0500, Thomas Dickey wrote: > > The null terminator should be checked only for the special case where > > the passed-in length is negative. > I agree in principle but the manual says > > The four functions with n as the last argument write at most n bytes, or > > until a terminating null is reached. If n is -1, then the entire string > > will be added. > Which reads to me like it ought to behave like printf(%.*s), > terminating at the first specified condition ‒ > a C string with a limit, not a range ‒ > so if it's supposed to be a range then maybe something to the effect of no - as I understand the history of this feature, if the length is specified, it's possible to send a null character in the middle of the string. > Also I just noticed the comma in mvwaddnstr is italic, thanks - I have a to-do item to extend the script which I've been developing to check manpages, to flag these (from seeing Branden's reports, etc). -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1055454: spamassassin: Spamassassin in Bookworm dropped SysVinit script
Hello, Am 19.11.2023 um 17:52 schrieb Noah Meyerhans : > Hi Patrik. I apologize; I was getting ahead of myself when indicating that > the spamassassin init script is gone by design. It's not, actually. It's > just moved to the spamd package, which was broken out from the base > spamassassin package. /etc/init.d/spamd is what you're looking for. Thanks. I have noticed that spamassassin has undergone a package split to spamassassin and spamd. Unfortunately, spamassassin did not pull in spamd, as I'd have expected on upgrade-time. This package-split is also not mentioned in the Debian package specific upgrade notes, where I'd have expected to find such an information: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html Shortly after my report I've restored Deb11 from backup due to too many unexpected things happening, leaving me with a half-broken system. SA being only part of the party. Something which is novel for me. I'm currently testing upgrades on less complex installs. Upgrades on earlier releases were mostly hands on at conffiles, but Deb12 upgrades have shown some… quirks for SysVinit users, mainly due to the lack of (IMHO) proper dependencies, and documentation. :wq! PoC
Bug#1056160: ITS: auctex
> PH == Preuße, Hilmar [2023-11-18] PH> On 18.11.2023 11:51, Davide G. M. Salvetti wrote: PH> Hello Davide, >> please, let me have some more time. I plan to release a new version >> within a fortnight. PH> Many thanks for fast response! I'll leave the ITS bug open, but I PH> won't drive the salve process forward. In case I can help somehow, PH> let me know. Hello Hilmar, I have a working 13.2 which sbuilds fine for stable. However, when I try to sbuild for unstable I get --8<---cut here---start->8--- Processing triggers for tex-common (6.18) ... Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.mQdiuvt8 Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common --8<---cut here---end--->8--- I have not yet digged into it, but it looks similar to #1051243. What do you think? -- Thanks, Davide
Bug#1056275: btm - upcoming rust-ratatui update.
Quoting Peter Michael Green (2023-11-19 17:12:56) > Package: btm > > I'm currently in the process of preparing updates for crossterm > to 0.27 and ratatui to 0.23. > > Btm's dependencies (both cargo and Debian) already allow the > new version of crossterm, but they don't allow the new version > of ratatui. I don't see anything too scary in the upstream > changelog and I've bumped the dependency and was able > to succesfully build the package. > > If you want to do further testing the new versions of crossterm > and ratatui are available in experimental. > > If no problems come to light I intend to upload them to > unstable in a week or so. Feel free to go ahead, and also to NMU btm if needed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1056235: Fwd: Bug#1056235: openfortivpn: not working anymore after upgrading from 1.20.5-1
Sorry, I should have tried using its command line tool before opening this issue. It works. So it is breaking something used by network-manager-fortisslvpn or network-manager-fortisslvpn-gnome. Le dim. 19 nov. 2023 à 15:53, Daniel Echeverri a écrit : > > tags 1056235 + moreinfo > thanks > > Hello! > > Thanks for your report, but unfortunately I can't reproduce this. I upgraded > openfortivpn to 1.21.0-1 in a sid box and it works fine. Could you make a try > with -v and share with me the output? > > El dom, 19 nov 2023 a la(s) 05:18, Patrice Duroux (patrice.dur...@gmail.com) > escribió: >> >> Package: openfortivpn >> Version: 1.21.0-1 >> Severity: normal >> >> Dear Maintainer, >> >> On a Debian Sid system, after upgrading from 1.20.5-1 and activating a >> previously working VPN config, >> I am not able to connect (ssh) any host by IP or name. >> And downgrading to 1.20.5-1 solves this. >> I do not see any message in the journal log that may be different from the >> working version. >> Unless that systemd-resolved is then not able to connect the VPN DNS. >> Looking at the upstream issues, may be this is something new?! >> >> Regards, >> Patrice >> >> >> -- System Information: >> Debian Release: trixie/sid >> APT prefers unstable-debug >> APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, >> 'oldstable-security'), (500, 'unstable'), (500, 'oldstable'), (1, >> 'experimental-debug'), (1, 'experimental') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) >> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not >> set >> Shell: /bin/sh linked to /usr/bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages openfortivpn depends on: >> ii libc62.37-12 >> ii libssl3 3.0.12-2 >> ii libsystemd0 255~rc2-2 >> ii ppp 2.4.9-1+1.1+b1 >> >> openfortivpn recommends no packages. >> >> Versions of packages openfortivpn suggests: >> ii systemd-resolved [resolvconf] 255~rc2-2 >> > > Also, Are you using a config file? Could you check if this file has the > correct permissions?? > >> >> -- Configuration Files: >> /etc/openfortivpn/config [Errno 13] Permission non accordée: >> '/etc/openfortivpn/config' >> >> -- no debconf information > > > Regards! > > > -- > Daniel Echeverri > Debian Developer > Linux user: #477840 > GPG Fingerprint: > D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#1055454: spamassassin: Spamassassin in Bookworm dropped SysVinit script
On 11/6/2023 2:53 PM, Patrik Schindler wrote: The removal of the sysvinit script was intentional. Per Debian policy section 9.3.1, "Packages including a service unit may optionally include an init script to support other init systems". Spamd provides a service unit. There is no requirement to support any other startup mechanisms or init systems, and I have no interest in supporting the old init script anymore. Thank you for your clear words. Hi Patrik. I apologize; I was getting ahead of myself when indicating that the spamassassin init script is gone by design. It's not, actually. It's just moved to the spamd package, which was broken out from the base spamassassin package. /etc/init.d/spamd is what you're looking for. noah
Bug#1056277: python3-pysrt: Opening files fails due to outdated 'U' mode
Package: python3-pysrt
Version: 1.0.1-3
Severity: normal
SubRipFile.open() and any use of the included srt command line tool fail
because the pysrt code uses the outdated 'U' mode which has since been
removed (traceback below). This has been fixed upstream for a while [1],
so updating the package should be enough to fix this bug.
For library use, loading the file outside pysrt and having pysrt parse
the string is a workaround.
[1]
https://github.com/byroot/pysrt/commit/17e1f58dab58b941abcbd035d9c6e2fcacba5600
Traceback (most recent call last):
File "/usr/bin/srt", line 33, in
sys.exit(load_entry_point('pysrt==1.0.1', 'console_scripts', 'srt')())
File "/usr/lib/python3/dist-packages/pysrt/commands.py", line 215, in
main
SubRipShifter().run(sys.argv[1:])
File "/usr/lib/python3/dist-packages/pysrt/commands.py", line 136, in run
self.arguments.action()
File "/usr/lib/python3/dist-packages/pysrt/commands.py", line 159, in
rate
self.input_file.shift(ratio=ratio)
^^^
File "/usr/lib/python3/dist-packages/pysrt/commands.py", line 197, in
input_file
self._source_file = SubRipFile.open(self.arguments.file,
File "/usr/lib/python3/dist-packages/pysrt/srtfile.py", line 152, in open
source_file = cls._open_unicode_file(path, claimed_encoding=encoding)
^^^
File "/usr/lib/python3/dist-packages/pysrt/srtfile.py", line 293, in
_open_unicode_file
source_file = codecs.open(path, 'rU', encoding=encoding)
^^
File "", line 918, in open
ValueError: invalid mode: 'rUb'
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-pysrt depends on:
ii python33.11.4-5+b1
ii python3-chardet5.2.0+dfsg-1
ii python3-pkg-resources 68.1.2-2
python3-pysrt recommends no packages.
python3-pysrt suggests no packages.
-- debconf-show failed
Bug#1043257: auctex: New upstream release 13.2
tags 1043257 +confirmed +pending thanks > XD == Xiyue Deng [2023-8-7] [...] XD> Dear maintainers, XD> A new upstream release of auctex has been available for a while, and XD> I've prepared a (somewhat crude) merge request[1] with refreshed XD> patches which maybe useful as a base to work on. Dear Xiyue, I reviewed your work: the patches have to be refreshed the way you did, thanks. I'm working on 13.2 packaging right now and will upload soon. XD> There are still several lintian warnings that I haven't figured out XD> how to fix I've worked on and fixed them. -- Thanks, Davide
Bug#1056276: E: The repository 'http://ftp.us.debian.org/debian bookworm-security Release' does not have a Release file.
Source: bookworm Version: 1.1.2+git20210715-2 Severity: important X-Debbugs-Cc: q53...@aol.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** This situation has existed since I upgraded to version 12 (bookworm) I have not found any work-around. This situation prevents me from updating or upgrading my computer system. Another issue is that 'grep' does not work. 'libreoffice Calc' does not work. synaptic package manager cannot fix broken packages! E: Unable to correct problems, you have held broken packages. E: Unable to correct dependencies Err:1 http://ftp.us.debian.org/debian bookworm/main amd64 libbatik-java all 1.16+dfsg-1 404 Not Found [IP: 2620:0:861:2:208:80:154:139 80] Err:2 http://ftp.us.debian.org/debian bookworm/main amd64 mariadb-common all 1:10.11.3-1 404 Not Found [IP: 2620:0:861:2:208:80:154:139 80] Err:3 http://ftp.us.debian.org/debian bookworm/main amd64 libmariadb3 amd64 1:10.11.3-1 404 Not Found [IP: 2620:0:861:2:208:80:154:139 80] E: Failed to fetch http://ftp.us.debian.org/debian/pool/main/b/batik/libbatik-java_1.16%2bdfsg-1_all.deb 404 Not Found [IP: 2620:0:861:2:208:80:154:139 80] E: Failed to fetch http://ftp.us.debian.org/debian/pool/main/m/mariadb/mariadb-common_10.11.3-1_all.deb 404 Not Found [IP: 2620:0:861:2:208:80:154:139 80] E: Failed to fetch http://ftp.us.debian.org/debian/pool/main/m/mariadb/libmariadb3_10.11.3-1_amd64.deb 404 Not Found [IP: 2620:0:861:2:208:80:154:139 80] -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055567: Error: gscan2pdf fails to compile
On 19/11/23 21:35, Jeff wrote: It looks like the version of libusb libsane was built against is not the same as the one you are running with. There are some similarities here: https://askubuntu.com/questions/1264001/error-installing-xsane-sane-hplip-etc-with-undefined-symbol-libusb-set-optio What does the following return? apt-cache policy libsane1 libsane-common libimage-sane-perl libusb-1.0 soumyanath@ganak-desktop:~$ apt-cache policy libsane1 libsane-common libimage-sane-perl libusb-1.0 libsane1: Installed: 1.0.29-0ubuntu5.2 Candidate: 1.0.29-0ubuntu5.2 Version table: *** 1.0.29-0ubuntu5.2 500 500 http://in.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 100 /var/lib/dpkg/status 1.0.29-0ubuntu5.1 500 500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages 1.0.29-0ubuntu5 500 500 http://in.archive.ubuntu.com/ubuntu focal/universe amd64 Packages libsane-common: Installed: 1.0.29-0ubuntu5.2 Candidate: 1.0.29-0ubuntu5.2 Version table: *** 1.0.29-0ubuntu5.2 500 500 http://in.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://in.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages 100 /var/lib/dpkg/status 1.0.29-0ubuntu5.1 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages 1.0.29-0ubuntu5 500 500 http://in.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://in.archive.ubuntu.com/ubuntu focal/main i386 Packages libimage-sane-perl: Installed: 5-1 Candidate: 5-1 Version table: *** 5-1 500 500 http://in.archive.ubuntu.com/ubuntu focal/universe amd64 Packages 100 /var/lib/dpkg/status libusb-1.0-0: Installed: 2:1.0.23-2build1 Candidate: 2:1.0.23-2build1 Version table: *** 2:1.0.23-2build1 500 500 http://in.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status libusb-1.0-0-dev: Installed: (none) Candidate: 2:1.0.23-2build1 Version table: 2:1.0.23-2build1 500 500 http://in.archive.ubuntu.com/ubuntu focal/main amd64 Packages libusb-1.0-doc: Installed: (none) Candidate: 2:1.0.23-2build1 Version table: 2:1.0.23-2build1 500 500 http://in.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://in.archive.ubuntu.com/ubuntu focal/main i386 Packages
Bug#1056275: btm - upcoming rust-ratatui update.
Package: btm I'm currently in the process of preparing updates for crossterm to 0.27 and ratatui to 0.23. Btm's dependencies (both cargo and Debian) already allow the new version of crossterm, but they don't allow the new version of ratatui. I don't see anything too scary in the upstream changelog and I've bumped the dependency and was able to succesfully build the package. If you want to do further testing the new versions of crossterm and ratatui are available in experimental. If no problems come to light I intend to upload them to unstable in a week or so.
Bug#1037192: sd: version is lower than in squeeze
On Mon, 23 Oct 2023 17:28:50 +0200 Orión González wrote: > A contributor suggested that 1.0 release should be on hold until some new > features get stabilized > https://github.com/chmln/sd/issues/203#issuecomment-1775390770 > > This might mean that the 1.0 release might take many more months. 1.0 has been released: https://github.com/chmln/sd/releases/tag/v1.0.0 I'm now preparing the update. -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055567: Error: gscan2pdf fails to compile
It looks like the version of libusb libsane was built against is not the same as the one you are running with. There are some similarities here: https://askubuntu.com/questions/1264001/error-installing-xsane-sane-hplip-etc-with-undefined-symbol-libusb-set-optio What does the following return? apt-cache policy libsane1 libsane-common libimage-sane-perl libusb-1.0 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1028238: Please update auctex to 13.1
tags 1028238 +confirmed +pending thanks I'm working on AUCTeX 13.2 and will upload soon. -- Thanks, Davide
Bug#1054730: trac: FTBFS: ValueError: ("Missing 'Version:' header and/or PKG-INFO file at path: /<>/Trac.egg-info/PKG-INFO", Trac [unknown version] (/<>))
Control: severity -1 normal Control: tag -1 + moreinfo Hi, I can't reproduce this FTBFS. Could you try again, please? I'll upload a new version, but it shouldn't make a difference.
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham,
On 19 November 2023 at 13:49, Graham Inggs wrote:
| On Tue, 14 Nov 2023 at 12:42, Dirk Eddelbuettel wrote:
| > Doesn't 'normal' do that?
|
| No, only serious and above are considered RC [1] and also for migration.
|
| This week, Paul Gevers and I spent some time discussing ways to move
| this transition forward.
|
| Referring back to some of your previous emails below.
|
| On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote:
| > We need to address the packages needing a rebuild. Mine (r-cran-lme4,
| > r-cran-rcppeigen). have been taken care of.
|
| We see the upload of lme4 1.1-35.1-2 on 2023-11-14 [2], and the
| changelog mentions a rebuild, but the upload of r-cran-rcppeigen
| 0.3.3.9.4-1 on 2023-11-03 [3] happened before the upload of matrix
| 1.6-2-1. Does r-cran-rcppeigen still require a rebuild?
I am upstream for RcppEigen.
And the upstream NEWS has
\item The interface to package \pkg{Matrix} has been updated and
simplified thanks to an excllent patch by Mikael Jagan.
\item The new upload is coordinated with packages \pkg{lme4} and
\pkg{OpenMx}.
So it contains a patch by Mikael which had been applied _permitting Matrix
1.6-2_ to get to CRAN. So for this particular pair it was the other way around.
And I acted accordingly as Debian maintainer for a package for which I am
upstream.
| On Mon, 13 Nov 2023 at 12:23, Dirk Eddelbuettel wrote:
| > I would appreciate it if someone could tickle rebuilds. To me a quick
| > informal touch of debian/changelog would do; if someone thinks this needs a
| > formal transition go for it.
|
| We don't believe only touching debian/changelog, or a binNMU, is
| sufficient. We were surprised that your r-cran-lme4 upload did not at
| least include:
| Depends: r-cran-matrix (>= 1.6-2-1)
| Without that relationship, r-cran-lme4 could migrate to testing and be
| installed on users' systems without the corresponding version of
| r-cran-matrix. It is no surprise that the excuses page for lme4 [4]
| is all red, because that is exactly what is being tested. More on
| this to come in my next email.
I can add that, and probably should have. And I agree with the sentiment in
your other mail that a transition is overkill here.
Matrix has 1304 reverse dependencies at CRAN [1], Mikael (in the two emails
he wrote at my urging) identified 14 packages that needed a rebuild because
they use Matrix header files (R packages can build against headers in another
package, this is more specialised use), and another 3 that had cached S4 (the
more complicated OO model in R) function signature.
So 17 out of 1304 is not exactly a general breakage. I think I found 6 out of
the 17 as being in Debian. I had dealt with three myself and then sent email to
initiate
simple rebuilds. But that went nowhere.
So I leave this in your hands. If you think that after all this needs a
transtion, I may shrug but will of course help.
And please dDon't get wrong: I am considering this to be an open problem
upstream. The R Core team, the CRAN team, and others are discussing, but the
CRAN system does not quite have our mechanisms even to push binary
rebuilds. So this is an ongoing and open issue.
Dirk
[1] See the R snippet:
> db <- tools::CRAN_package_db()
> length(tools::package_dependencies("Matrix", reverse=TRUE, db=db)$Matrix)
[1] 1304
>
so 1304 are found right now at CRAN, and 17/1304 is about 1.3%. We seem
to have 6 identified out of about 138 (per apt-cache rdepends ...)
which is a little higher at 4.3% which is normal as 'heavier' packages
are more likely to be packaged. But net-net it is still only one out
over twenty packages around Matrix.
|
| Regards
| Graham
|
|
| [1] https://www.debian.org/Bugs/Developer#severities
| [2]
https://tracker.debian.org/news/1478501/accepted-lme4-11-351-2-source-into-unstable/
| [3]
https://tracker.debian.org/news/1475888/accepted-r-cran-rcppeigen-03394-1-source-into-unstable/
| [4] https://qa.debian.org/excuses.php?package=lme4
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
Control: tags -1 + moreinfo Hi Andreas On Mon, 13 Nov 2023 at 09:10, Andreas Tille wrote: > Thanks to the hint from Charles I found that SparseArray is not new in > Bioconductor and we can build the previous version with the current > packages in unstable which I did and uploaded to new. Thanks. Since I count about 30 r-bioc-* packages with direct dependencies on r-cran-matrix, we'd rather not entangle the r-bioc* transition with rmatrix (#1055922), so please remove the 'moreinfo' tag once SparseArray has cleared NEW, and rmatrix has migrated. Regards Graham
Bug#1055567: Error: gscan2pdf fails to compile
On 19/11/23 16:15, Jeff wrote: Please reinstall the packages: sudo apt reinstall libsane1 libimage-sane-perl and try to start gscan2pdf again. This is what I get soumyanath@ganak-desktop:~$ gscan2pdf Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined symbol: l ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93. at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144. Compilation failed in require at /usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 8. Compilation failed in require at /usr/share/perl5/Gscan2pdf/Document.pm line 12. BEGIN failed--compilation aborted at /usr/share/perl5/Gscan2pdf/Document.pm line 12. Compilation failed in require at /usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7. Compilation failed in require at /usr/bin/gscan2pdf line 61. BEGIN failed--compilation aborted at /usr/bin/gscan2pdf line 61. Undefined subroutine ::Sane::_exit called at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 190. END failed--call queue aborted at /usr/bin/gscan2pdf line 61. ---
Bug#1055155: bookworm-pu: package exim4/4.96-15+deb12u3 (2nd try for new bug)
Control: tags -1 + confirmed On Sun, 2023-11-19 at 11:26 +0100, Andreas Metzler wrote: > On 2023-11-04 Andreas Metzler wrote: > [...] > > Thank you, updated. > > Another iteration, adding > + 76-14-Lookups-Fix-dnsdb-lookup-of-multi-chunk-TXT.-Bug- > 305.patch Fix > regression in dnsdb in CVE-2023-42119 fix. (Upstream bug 3054) Please go ahead. Regards, Adam
Bug#1056235: openfortivpn: not working anymore after upgrading from 1.20.5-1
tags 1056235 + moreinfo thanks Hello! Thanks for your report, but unfortunately I can't reproduce this. I upgraded openfortivpn to 1.21.0-1 in a sid box and it works fine. Could you make a try with -v and share with me the output? El dom, 19 nov 2023 a la(s) 05:18, Patrice Duroux (patrice.dur...@gmail.com) escribió: > Package: openfortivpn > Version: 1.21.0-1 > Severity: normal > > Dear Maintainer, > > On a Debian Sid system, after upgrading from 1.20.5-1 and activating a > previously working VPN config, > I am not able to connect (ssh) any host by IP or name. > And downgrading to 1.20.5-1 solves this. > I do not see any message in the journal log that may be different from the > working version. > Unless that systemd-resolved is then not able to connect the VPN DNS. > Looking at the upstream issues, may be this is something new?! > > Regards, > Patrice > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, > 'oldstable-security'), (500, 'unstable'), (500, 'oldstable'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages openfortivpn depends on: > ii libc62.37-12 > ii libssl3 3.0.12-2 > ii libsystemd0 255~rc2-2 > ii ppp 2.4.9-1+1.1+b1 > > openfortivpn recommends no packages. > > Versions of packages openfortivpn suggests: > ii systemd-resolved [resolvconf] 255~rc2-2 > > Also, Are you using a config file? Could you check if this file has the correct permissions?? > -- Configuration Files: > /etc/openfortivpn/config [Errno 13] Permission non accordée: > '/etc/openfortivpn/config' > > -- no debconf information > Regards! -- Daniel Echeverri Debian Developer Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Andreas
On Sat, 18 Nov 2023 at 19:18, Andreas Tille wrote:
> We need some means to follow ABI changes. In Debian we could use
> something like r-matrix-abi-VERSION.
Indeed, this is one solution. As you saw in [1], upstream now provide
an ABI version and a way to extract it:
> Matrix will commence ABI versioning in 1.6-2. The ABI version will be
> available
> in R as Matrix.Version()[["abi"]] and in C as R_MATRIX_ABI_VERSION (from
> header
> Matrix/Matrix.h). It is numeric_version("1") in Matrix 1.6-2 and _implicitly_
> numeric_version("0") in Matrix < 1.6-2.
However, since rmatrix has over 100 reverse-dependencies, and only a
very small number of these are broken by the ABI change, we feel this
may be overkill, but wouldn't dissuade anyone from proposing patches
to implement this.
Another option is simply to add a versioned dependency on
r-cran-matrix to the affected packages, e.g.:
Depends: r-cran-matrix (>= 1.6-2-1)
...but this requires a source change and an upload, is error-prone,
and a binNMU would not be sufficient.
We liked the change you made to r-cran-tmb [2], as this allows the
affected packages to be binNMU'd and gain a versioned dependency on
r-cran-matrix. Would you please apply this to the other affected
packages (only r-cran-irlba and r-cran-openmx, if I understand
correctly)?
Unfortunately, it seems the two-sided dependency introduced
subsequently [3], which produces:
r-cran-matrix (>= 1.6-2-1), r-cran-matrix (<= 1.6-2-199)
...is too strict, and r-cran-tmb already needs another rebuild due to
the upload of rmatrix 1.6-3-1. Would you please revert that change
and upload?
Regards
Graham
[1] https://stat.ethz.ch/pipermail/r-sig-mac/2023-October/014890.html
[2]
https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/92579f72c2db4d51a45cf317f580d790da158f4f
[3]
https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/0a4d35d10f9c875863fa0238287cee8ab25aecdd
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
Package: dropbear-initramfs Version: 2022.83-2 Severity: normal Tags: patch Dear Maintainer, I am building reproducible initramfs using SOURCE_DATE_EPOCH. This works great, but unfortunately, dropbear-initramfs breaks reproducibility, because it creates a randomly named /root-XXX directory to store the authorized_keys file. This is done in debian/hooks/dropbear. It would be great if this could be fixed. One solution would be to simply always use /root-dropbear-initramfs. I have attached such a patch. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dropbear-initramfs depends on: ii busybox 1:1.35.0-4+b3 ii dropbear-bin 2022.83-2 ii initramfs-tools 0.142 ii udev 252.17-1~deb12u1 Versions of packages dropbear-initramfs recommends: ii cryptsetup-initramfs 2:2.6.1-4~deb12u1 dropbear-initramfs suggests no packages. -- no debconf information --- a/debian/hooks/dropbear +++ b/debian/hooks/dropbear @@ -24,7 +24,8 @@ for so in $(ldconfig -p | sed -nr 's/^\s*libnss_files\.so\.[0-9]+\s.*=>\s*//p'); copy_exec "$so" done -home="$(mktemp --directory -- "$DESTDIR/root-XX")" # avoid collisions with $rootmnt +home="$DESTDIR/root-dropbear-initramfs" +mkdir "$home"
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Dirk On Tue, 14 Nov 2023 at 12:42, Dirk Eddelbuettel wrote: > Doesn't 'normal' do that? No, only serious and above are considered RC [1] and also for migration. This week, Paul Gevers and I spent some time discussing ways to move this transition forward. Referring back to some of your previous emails below. On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote: > We need to address the packages needing a rebuild. Mine (r-cran-lme4, > r-cran-rcppeigen). have been taken care of. We see the upload of lme4 1.1-35.1-2 on 2023-11-14 [2], and the changelog mentions a rebuild, but the upload of r-cran-rcppeigen 0.3.3.9.4-1 on 2023-11-03 [3] happened before the upload of matrix 1.6-2-1. Does r-cran-rcppeigen still require a rebuild? On Mon, 13 Nov 2023 at 12:23, Dirk Eddelbuettel wrote: > I would appreciate it if someone could tickle rebuilds. To me a quick > informal touch of debian/changelog would do; if someone thinks this needs a > formal transition go for it. We don't believe only touching debian/changelog, or a binNMU, is sufficient. We were surprised that your r-cran-lme4 upload did not at least include: Depends: r-cran-matrix (>= 1.6-2-1) Without that relationship, r-cran-lme4 could migrate to testing and be installed on users' systems without the corresponding version of r-cran-matrix. It is no surprise that the excuses page for lme4 [4] is all red, because that is exactly what is being tested. More on this to come in my next email. Regards Graham [1] https://www.debian.org/Bugs/Developer#severities [2] https://tracker.debian.org/news/1478501/accepted-lme4-11-351-2-source-into-unstable/ [3] https://tracker.debian.org/news/1475888/accepted-r-cran-rcppeigen-03394-1-source-into-unstable/ [4] https://qa.debian.org/excuses.php?package=lme4
Bug#1056273: RFS: c-evo-dh/1.10-1 -- Empire Building Game (data files), C-evo: Distant Horizon
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "c-evo-dh": * Package name : c-evo-dh Version : 1.10-1 Upstream contact : Peter * URL : https://sourceforge.net/projects/c-evo-eh/ * License : GPL-2+, CC-BY-SA-3.0-US, CC0-1.0, CC-BY-3.0 * Vcs : https://salsa.debian.org/PeterB/c-evo-dh Section : games The source builds the following binary packages: c-evo-dh-gtk2 - Empire Building Game (GTK2), C-evo: Distant Horizon c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon c-evo-dh-data - Empire Building Game (data files), C-evo: Distant Horizon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/c-evo-dh/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.10-1.dsc Changes since the last upload: c-evo-dh (1.10-1) unstable; urgency=medium . * New Upstream Release, (Closes: #1055837) * Add NEWS file Regards, -- Peter Blackman
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Sun, Nov 19, 2023 at 01:54:02PM +0100, Hilmar Preuße wrote: >... > I can patch out that version check as found by Samuel, but I don't see how > that would solve the core dump or the SIGABRT, which was reported. I hope > lua_error(L) is not the equivalent of "exit with SIGABRT". ;-) >... It is. https://www.lua.org/manual/5.3/manual.html#lua_error int lua_error (lua_State *L); Generates a Lua error, using the value at the top of the stack as the error object. This function does a long jump, and therefore never returns (see luaL_error). The SIGABRT is generated by calling abort(): https://sources.debian.org/src/lua5.3/5.3.6-2/src/lapi.c/#L1117 https://sources.debian.org/src/lua5.3/5.3.6-2/src/ldebug.c/#L649 https://sources.debian.org/src/lua5.3/5.3.6-2/src/ldo.c/#L130 > Hilmar cu Adrian
Bug#1056269: New feature supports : PoW
Package: tor Version: 0.4.7.13-1 Tor has a mechanism to prevent DoS attacks as much as possible, but it requires adding the `--enable-gpl` parameter to the build. Use `tor --list-modules` to verify the inclusion of `PoW: yes`. I sent this to Fedora EPEL is supported, details here:https://bugzilla.redhat.com/show_bug.cgi?id=2247828 Ref: https://community.torproject.org/onion-services/advanced/dos/
Bug#1056268: rust-thiserror: please update to v1.0.50
Source: rust-thiserror Version: 1.0.49-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v1.0.50. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaC44ACgkQLHwxRsGg ASEveQ/+JJcti6QM5VnI6XpSHlIhraCxSH0K4+VAQt6yeNUV6+poSf0W3X2z0D+a PK4yAxOb966R0is5zUig2P+FdHU4H3JHgtfZ9Y4SRTjupARKHG8jwm2GTvO8aTTZ 1y4hlFFrqTR7An+mBXLevlIR180Rni1vFQ2kgArs4u+znQy4wBMdH7KWL0cg8vjI B79DH54771fAb9R1sOATA6pYobI8TtVEcuKuDDTTB9FOiy100/HSrZNsYrHVX8D8 hFAKHUD5zIO+L+I3cdhqTo/NKAO40Yl/RGNg9CeGTnJ8icm903HI0Bk2VOIGyEeO KKG/oiG8tFNgMPVempsouyRjbwwpRHtBxKdlzlyR3p0/sMKjxHJY41ueEFCaQu1z YnbKTH/qZN3RxsOeYcY/FqzG5+2xDA9RoRtaiZ2JQ2vo4CdWXgwgKGPI8esPxXBe vqW8EI/JY3BDjnU5JLaM+/+5CMx9yDHGm4aNZY99AahyHvbBnLOLRL3v1HK1d7Ox QrjyQD7AOFgUCa9evvco6tPcKTCEGzTnTjxDAh2YdZlEIlZJY5Q3QjzFnoUwn6lW u5eVyA06WgYF72p+r6u30++Vs9lz3fcvrdXe2bD2EO0IUwRFwC8JsuHoJeOr8yKD gm0VPTv0V9PkYXh57XKP4lOVsASgT9wy5BLt/AEGzqm/QRPmUQQ= =KmsK -END PGP SIGNATURE-
Bug#1056267: rust-cpufeatures: please update to v0.2.6
Source: rust-cpufeatures Version: 0.2.4-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v0.2.6. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaCjwACgkQLHwxRsGg ASElyQ//epbOMg7KrdbK5EqgtJKONTsYukrrxHmdE0Y5MtUGuvdQuoL8cnEWJKSO m2mX5GQQ2gwiu41I7+qkMUfaljokrLQKeeSnNKineG/hip0ENnHcQWF09YsqJOxZ 3PI5oBHjCKYHNkvFBC9voJM8rI+Vwb/D5MaQXsnq1AnxgYirfm49QZjaoAH+w2Ge Qcos8jaPaAbFITbdPyCGMlUTeriwetYCp5Oj+XHS+zz67Wic3q8X+PJ4BwYLQrT4 Lt+gqz2I4v8mihw3B660k71btm8sJNquUnswJKl2YnJC1dYbA5ZmvBrsSRZ3EwIG ui37T+JbQlEXYP5JiJjfa5Mlzvtm5rskFRr6KNLEboW76fQPRzNkzmHg0KibBooI /b6sbf0T40gVq1KPekfVWHW4wagn8rGlGnkcNJlxc72QQw2El3RdajZq7YV1ZnZr t6SzF13LkgWqLzWZ5UY83g/75O5VINJJ7N2WkenXjHvNdBqOfLWD/XdpB03GMo5X PdYZImF0Hef2VVR1oSGO68XB8b5cxprNF9P0FzzOMtUnz8vWbBQ8y9n1ZzDtWKv4 tf1AN0P4Lu/1aQlqSNySWhT99Sa6n27ifKI8ckrr9p5LfSE78Pazbo29FYHaT3q4 3g0TP8vSRXiWN/kKaOhICQpmBdnmtNnw4h/aPdUUm8G0IXgkztI= =fYF/ -END PGP SIGNATURE-
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 2023-11-19 13:54:02 +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: > > On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote: > > > On 11/18/23 20:18, Samuel Thibault wrote: > > Hi all, > > > > > nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild > > > > against new zlib" > > > > > > > Thanks for filing the NMU bug. > > > > > > > So a binnmu of the texlive-bin source package seems needed on all archs > > > > to fix installing texlive-binaries. > > > > > > > > > > I tested if recompiling solves the issue and it does. Hence I bump > > > severity > > > of the NMU bug the get a solution ASAP. > > > > I don't see how a binNMU would solve the problem. > > > > A proper fix would be either to: > > 1. patch the version check out of texlive-bin (preferred), or > > > I can patch out that version check as found by Samuel, but I don't see how > that would solve the core dump or the SIGABRT, which was reported. I hope > lua_error(L) is not the equivalent of "exit with SIGABRT". ;-) > > I still suspect that something broke in the API of zlib, the zlib people are > not aware of. That crash is the fault of lua_error(L). Removing the version check including the call to lua_error is the proper fix for this. If any of the binaries of texlive-bin require a minimum version of the zlib, this needs to be reflected in Depends and not with a deliberate crash. > > 2. ensure texlive-bin has package dependencies that match this runtime > > check > > The zlib people, did not change the API version or created a version > statement in the depends line like "Depends: ... zlib1g (>= 1:1.3)", hence > I'd add an artificial "Breaks: ... zlib1g (<= 1:1.2.3)" to my > texlive-binaries package to make sure 1.3 is in place, when the new > texlive-binaries comes in. Correct? No, that's certainly the incorrect fix. Especially if that is hard-coded. Cheers -- Sebastian Ramacher
Bug#1056266: rust-futures-util: please update to v0.3.29
Source: rust-futures-util Version: 0.3.28-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v0.3.29. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaCagACgkQLHwxRsGg ASGyOhAAqeFHYIdaDsTeBMjTcTf7sZZyabGiwkxTgzsxJql1ONcNypD58BPxz9NJ 5siaIILnqGmCepbnpGF1xuuu2slhCZixqbUcOFTUX2WYUYGbVAg/Gf2q7P7NzNEI G4QSPunRx3LVKxGXEyz6rF+cBXbYjoDQgl3w/kvAPGFwocm+o+8Ubi52RTCxCrDb Bl01ed6WsbDbcDH5Nl3+cga/dI80yudd+8+lY6Mq9nrloRI1H5CzOYgZdYD6WACz qYzmSGmF7TMG9ez4rkuNtSh/eHPCVbyPuxlgajCq+hGNQiRW+dnMjHwj8wC/FQvR scJN72u8Febne6FZkQDliwGzZ7Yim+rKdjUTVCj1rUSrYKhtnwamTYhhXpYrMdj3 mMaMNjGiu9owncbFzeUSnFc0o2kEBMTbGWvYl2f4uqLdKUUc/QoG8gXnHQ8rC2KC rrahCeG6Yos9F+0i8g96PIQtk2lemDZ4NkqjUokU0/P5/CLNTkSBRmg/d8Ze8ZJ+ jCSMqjMlS7EQW4GWilN3rG+Nii0jn9gq9CowNx5efuJiWXZXY9eThC2nnDzhYeBa 5f5W3WfWacevvo4xQF/Vl8ttdYuRbJSWAGp/eHLztdCFeBS0Y2ppg2IScB3SGi6z TZ3JJAHlMK35uS7V4f8eeuoJToFNelasYhh96ff6bf5pAJs6ieQ= =oEIt -END PGP SIGNATURE-
Bug#1056265: rust-futures: please update to v0.3.29
Source: rust-futures Version: 0.3.28-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v0.3.29. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaCWsACgkQLHwxRsGg ASGi5Q//VbvDpjNCjD5Q+I29aoH9eg/SorqHnhM7Sv1eBpVOpv6A4u2MESwXBBkw n4iTWG7s72omdxhxmU4y9H464b1euCIqOkz2jCqLuKKjqnrX0g5v5xne89Ajup4V x2XoN6d+Khl+nwJZYV3FxFlxdpm5V+kWghL1SlgsTglZ20jn04N+ewTraeLCz96g AESftAnfcrlnF61dZ4MT3MRDyZmHWEDsv8pG0kerPfx8r1dw6bU1c2VgevLvcoBV 7MSni0B0XHBlSyNym2HLs5zQGqRmKKe8RlB/b1FASCURtB3cb/Zh/ke3HM+pAU01 61Wupc+c3ix37zpODrXL3ZDXMBzoLZU/RywrK+jfhNVP4IgrV8d4TOO0vhWsPCSJ 8uF/ShYzF+BwemgEeajlJlioykFtOqVTf0AAkPaLow3PyqIAckjb/DL5/XiojKyi MT3QCN23YDGDsT1idsmu/feEHl1lHuTV0+gbgULBbStlLHBJwtbSzX56i4hQckSK +SiabyQt6R/56gJa93+O+nublOuHBheduPOkLZaGOM7qzjEz4WrV+XrKOAjtFkQf OgnMu0XlqLA7Sk/T7dloH3CTQxkbhaRhR3NR2fSPWQHLrtXGEcM5/aRmXDkiGVtn Ub1g7DmleZSU3s4BomDF8Xpdn5OhcifUgzR78sEh1CTouyeqT5k= =tbEw -END PGP SIGNATURE-
Bug#1056264: rust-bytes: please update to v1.5.0
Source: rust-bytes Version: 1.4.0-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v1.5.0. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaCQIACgkQLHwxRsGg ASHuMQ//dXxdEqE3A6Uf8+N6/rHiduQZnGJYuBVuIy8m2bNOj06JoHfEwAO7q96t kUE3k51XpxHN5YPjC/IMn++WOV+RULaQZbF8xUSTPIS0EIYonWBnmnkFccfQWhjc w1nx/elQD0mgl4nThMv+LU+vUsdxEXZl7vCovC54Fnaav7M4QfGnRvmC5AVWlxRw Beif1WQ3g9tgL4OvNrOjzCUJt/jbVOTmHfaYt45hkVsLbh/FGI7U70+rg+ll6LND 1c9ZZgXOra0zjg6sHCleLZAOBKSJWl9OfhxXSuL2t4mga0hG5JC76jnQLLobFr2q oIwzZf59ude1vO1n1QC5JCkAC3/GKomwERy4UhKUsRhDl4egpiVN/PrWiCJel5i2 K5b6P2R/hFRZJz3nJO3qo3kRXf8yLCSjt2hNmutU81uAIYSYObU4b/ySaG/xFLpV 47eC6TaCCeINbLTuG8zdGaJspE0E/17glTpJZyawdKiIYBhq4yzEz08o9KGNEvWC OJkA4i3yp/NfGQ6FiItI2/VYXorv+VVPtG+3E/tY7jF8nx7OU+oLjDEZrivvTNgM KuG90G01yFDBINqa5nC9IjydIPjDCBqWmzgKve4OWlaDXcN6wGtsFfD1lqaBaNoh jAIFH+N+aWYJ7yzXeYTjN0j51cNlZwRKFT0YXfgbFQhSrggnRMk= =54wM -END PGP SIGNATURE-
Bug#1056263: rust-byteorder: please update to v1.5.0
Source: rust-byteorder Version: 1.4.3-2 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v1.5.0. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaCLgACgkQLHwxRsGg ASGSsg//VMuDFN+/gpAMke5R2iKomXfuE0BXUJsLMqn38duvvA7k75XL36c2nqjV IeusRjyqSzuAPRRQZTxIRIOENkdqgRi35EjaRFWghaR8P+y8Q8kU0e+dHqLNT9uT zsCLmmyTE5wBOaTdPmI8NtmcjSoYMm3VCG7J/QdymYZRSeh4rqhakkxEpncRUAfF IkGdyi/slFs4INrE93tlaUFhaJjAR+mUYC7sb2C+h5sykxEDTXR4ynz5YYJHPGTb l4X649KEONcDDYrCOh7lU9Nkk4KIBpo64w/qVWQErtCMpbys7jlKve0fDc8ELinx IxBeW8UBKw5RFwZ+Dadme4ISxUF9NiIvQhFRGugW+E/S5jJktmDJ4Gnw5WTIB798 3tTeemn8CJttA0xAWVQosZwJebFhevHHq5BTKALQWoFt6l38n0Meq01BfOvK5k1b lIt6CBbcb7OM65Jmd5VNLytRWWlvM6h59PyesdLFzxtPFunclmtmwoBS7dD/tAOW mwdMvkOIsAiiD+e+ZUUVkOALkPnISC9dh865ThylkAs+LBd1a80hZBAIX8aM4sbj 0RnpXGY0W49BKf18L+bM2wtjU/pg5rU1JLTPZjTnw2qFgAfk0sZWay1+Hj3gIrTK 7z867ju3JKvwXmrfhwhiDZ2dSdvjOBzs+e00yP/+NhfRq6fIbpE= =xLgm -END PGP SIGNATURE-
Bug#1056262: rust-base64: please update to v0.21.5
Source: rust-base64 Version: 0.21.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v0.21.5. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaCHgACgkQLHwxRsGg ASGCdw//SNdDJHSrfBapN5aZxH2ZP0aQFwE/sH7UOgp5fKpSGetApj61Rn/qzgpZ ONGfqBioj4o1br2JxphRmguTUqZWqwzi0cLAMQhvX6+OtDtzPQGimX5+QkqQROoU +ti6RacJLsg/JhnhSIx/cJmVnxtuK8vkNhWCCGsV2GhUwQPRmqQzRzCIARvzmFYg SHKzGtKnBbOT0+eavnA5xzpxiC0cg/ydDiKV3+pDvQr1G9HY8DCaMoWEGnEIi/L/ Gfw7KGQUN2ZvI5sf4A1LoppkiHqUGIHKUjzg+vkbB4U0mhTpL/+HPD6UOYOe0gYY P3Eizvpfd0GfFI0ffXNPKeY+wp6yNOeU/XlWNdSB5n6nGbhdWjvNJKNq7aSVoobN 97S+0EH05by6Y122LOsE+ZoWAp/uPCBi24mwPFxRQV7lvktBVl2K97ynKcc34lbZ a01Lq3JOgeGobC3yFeR/376T6Ak2eVr5wdBJqIjuUzcAYLM9LjUFIvvT8ZIuSiso unXuN92y9FnKzv8yz/StPePhF1AzOFo4vw8Z9Ibe9mp6/JvQbsbO3pZjnatGdzxt 4q4bww7DyG5lPuxVppDj1eltjwpc3YN+MFLndzaHXCFGn5z6G6JbxLENd5gYZUcv w3P9k3mbciIoGXS1wwWLT2FrkiiB0bDaicF+sSbLW7Tn3KQHo3k= =Apm7 -END PGP SIGNATURE-
Bug#1056261: rust-asynchronous-codec: please upgrade to v0.7
Source: rust-asynchronous-codec Version: 0.6.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please upgrade to (or separately provide) newer branch v0.7. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaB+oACgkQLHwxRsGg ASE0lg//X6tbskEimSWk8tkObR6HEhpcWhAZB6UaVSWKKrJHWmDx5xFkYJrwH70m yTL/tD9Upe9kUmFAnxygKFszVPPH0xwWcgjHJ6cKxts0hfa1g73H5UJyNDbv6KMn OlYbuSr+s9VlGi0hu+JlOhCuQhfJXfUo/0ZMQaRfiQf7pl04tz7tsCnE0/IvcRUP gUXQGmOrL5XnKMot2+4g7lJ1tS4oHd+W68+C3+2nS0GVs8hpTJx7iZBT6MWUVUWJ 4hbmJRyQglhCWz7zyOUOdSzmnWthjKtSCYhtyGMzPWnOzqCHgvtmItq++PeVzO9o htA86PvR4R7taQ30DQmwLdv1+i5oiBs2PExOzxyi1kRG2E1FXIHHtaC41n1X5suA kRRBl6vWFOMRtu/WrW/Uysm5Xn6bCSs66Az1mmZ1kq3vrUnoIt0u07UtTAQJjM3t FLGpfVB6Uce0k9CFyQnfMyPUeylrjLr10KWLzthR88OV/7czzx/OOBdheypuM5Jh p7yWz8CnAn8ObJUCBRpYh362FClvzapn7ESkY6XB/AJkybAw10rK52cyIKvLMoD/ qp7pcw6+VQDj/LAwzIlvaC879Ya8BMGCy0CSg2xfMf7LkNwLeG8+j7nWuOLZGZqO c/Ga0TUszCdCgaUiFMKLKJiSWNus8yP0UGlwTtsCSOlSkSDCTnY= =vGzO -END PGP SIGNATURE-
Bug#1042646: dh-virtualenv: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'
Hello,
to make the package build in a buildd chroot some more adaptions are
needed:
- Depend on python3-docutils (which was pulled in before by
python3-sphinx)
- Drop debian/dh-virtualenv.doc-base as the documentation is missing
now
- Don't call dh with --with sphinxdoc
The complete deb diff now is:
dpkg-source: warning: extracting unsigned source package
(/home/uwe/debsrc/dh-virtualenv_1.2.2-1.4.dsc)
diff -Nru dh-virtualenv-1.2.2/debian/changelog
dh-virtualenv-1.2.2/debian/changelog
--- dh-virtualenv-1.2.2/debian/changelog2023-02-02 20:10:21.0
+0100
+++ dh-virtualenv-1.2.2/debian/changelog2023-11-17 19:40:18.0
+0100
@@ -1,3 +1,10 @@
+dh-virtualenv (1.2.2-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop Sphinx docs (Closes: #1042646)
+
+ -- Uwe Kleine-König Fri, 17 Nov 2023 19:40:18 +0100
+
dh-virtualenv (1.2.2-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru dh-virtualenv-1.2.2/debian/control dh-virtualenv-1.2.2/debian/control
--- dh-virtualenv-1.2.2/debian/control 2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/control 2023-11-17 19:40:18.0 +0100
@@ -2,26 +2,24 @@
Section: python
Priority: optional
Maintainer: Jyrki Pulliainen
-Build-Depends: debhelper-compat (= 12), python3,
- python3-setuptools, python3-sphinx, python3-mock, dh-exec,
- dh-python, libjs-jquery, libjs-underscore,
-# python-sphinx-rtd-theme doesn't exist in distributions
-# predating Debian Jessie and Ubuntu Xenial. On these legacy
-# systems:
-# 1. Comment the dependency below.
-# 2. pip install sphinx_rtd_theme.
-# 3. Proceed with your build process (typically dpkg-build).
-# See https://github.com/spotify/dh-virtualenv/issues/230
- python3-sphinx-rtd-theme
+Build-Depends:
+ debhelper-compat (= 12),
+ python3,
+ python3-docutils,
+ python3-setuptools,
+ python3-mock,
+ dh-exec,
+ dh-python,
+ libjs-jquery,
+ libjs-underscore,
Standards-Version: 4.5.0
Homepage: https://www.github.com/spotify/dh-virtualenv
Rules-Requires-Root: no
Package: dh-virtualenv
Architecture: all
-Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
${sphinxdoc:Depends},
+Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
virtualenv | python3-virtualenv (>= 1.7) | python${pyversion}-venv
-Built-Using: ${sphinxdoc:Built-Using}
Description: wrap and build Python packages using virtualenv
This package provides a dh sequencer that helps you to deploy your
virtualenv wrapped installation inside a Debian package.
diff -Nru dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base
dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base
--- dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base 2022-08-25
21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base 1970-01-01
01:00:00.0 +0100
@@ -1,9 +0,0 @@
-Document: dh-virtualenv
-Title: dh-virtualenv documentation
-Author: Spotify
-Abstract: This manual describes dh-virtualenv and how to use it.
-Section: Programming
-
-Format: HTML
-Index: /usr/share/doc/dh-virtualenv/html/index.html
-Files: /usr/share/doc/dh-virtualenv/html/*.html
diff -Nru dh-virtualenv-1.2.2/debian/rules dh-virtualenv-1.2.2/debian/rules
--- dh-virtualenv-1.2.2/debian/rules2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/rules2023-11-17 19:40:18.0 +0100
@@ -1,9 +1,6 @@
#!/usr/bin/make -f
DH_ARGS ?=
-ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
- DH_ARGS += --with sphinxdoc
-endif
PYTHON_VERSION := $(shell python3 -c 'import sys; print("%s.%s" %
sys.version_info[:2])')
@@ -22,9 +19,3 @@
override_dh_gencontrol:
dh_gencontrol -- -Vpyversion=$(PYTHON_VERSION)
-
-ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-override_dh_installdocs:
- python3 setup.py build_sphinx
- dh_installdocs doc/_build/html
-endif
I'll upload that to DELAYED/7 after sending this mail.
Best regards
Uwe
signature.asc
Description: PGP signature
Bug#1056260: RFS: ifstat/1.1.1-1 [ITA] -- InterFace STATistics Monitoring
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ifstat": * Package name : ifstat Version : 1.1.1-1 Upstream contact : Matthieu Baerts * URL : http://gael.roualland.free.fr/ifstat/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/ifstat Section : net The source builds the following binary packages: ifstat - InterFace STATistics Monitoring libifstat-dev - Ifstat Development Files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ifstat/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ifstat/ifstat_1.1.1-1.dsc Changes since the last upload: ifstat (1.1.1-1) unstable; urgency=medium . * New Upstream version (GitHub) * Drop patch adopted upstream * Adopt package (Closes: #1050469) * Fix man page spelling (Closes: #617336) * Convert to debhelper 13 * Add watch file * Change ISO-8859 encodings to UTF-8 Regards, -- Peter Blackman
Bug#1056259: rust-arrayvec: please update to v0.7.4
Source: rust-arrayvec Version: 0.7.2-2 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) v0.7.4. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVaB2YACgkQLHwxRsGg ASEQWA/+I0kYqObhBXK2l2LNcHU+JVL21woubzhqzJhKp2z1pjR92tVYuPPMRHn4 jmNiXdsHqUoVdofm13MYLakJYeBwqIeZxI9hOvyx161PaTAeXqA7sKQn0gNoNvou gz1iHMHl0ogkzud9RAY9JpbWulho3fIVkd/cu8Od2tWtfKIcIZ6qa1Zs29PTy2+V h+C+51fn8jlOKIfWgTRtwzoPhnnUSKpWPrrXrwfsbiQ6mbJHP94qOEGe8j0mtHM9 uzT2eD9DqhPWNE7jxkOgDNiV0ZvA3epc75Zf5lWq21CtaqZ8TkXFsWoazm2SRPKk Yf+iQsU4zHCD/mKqFHcyj8wEbwhgQ8L/20rUFRjbYKNo6gXUc3bFMiu4GI5A0Hk9 JAmm5Z5ipm/5oyG+ibTUQLmX+h2YZwC99grvEiDA9R1xQT0l5Bb9ns1nqXL06q6V FGY2mU/TEHyqayUz5eXMTJ4LvIOfBUATJ9C5yNy5SZKsSRFbiT1bU3xydzsk6mY8 XsYfvDcfM5VeGrExII1TZTWkuKUe+m2AqmDFlD0FXwEZMfVrHmFwCcLQmgFvfJEr sej3WVNeYlswhQ9Norn2wSciAmVIUfVlvFT0b/GSz8TSTD5vja8sbek7s4xej3MP gy1lh7k4OQRozdE4Kl3PrKdc0KaGrxjKJytMVD42FFTLbA95LAY= =C9eF -END PGP SIGNATURE-
Bug#1056253: rust-ripasso-cursive - FTBFS with rust-ripasso 0.6.4
On 19/11/2023 12:14, Peter Michael Green wrote: Package: rust-ripasso-cursive Version: 0.6.1-1 Severity: serious Tags: trixie, sid It appears, that despite the version number indicating a compatible release, that the new version of ripasso broke the build of ripasso-cursive. https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/rust-ripasso-cursive.html error[E0425]: cannot find function `push` in module `pass` --> src/main.rs:941:29 | 941 | let push_result = pass::push(().unwrap().lock().unwrap()); | not found in `pass` | help: consider importing this function | 18 + use ripasso::git::push; | help: if you import `push`, refer to it directly | 941 - let push_result = pass::push(().unwrap().lock().unwrap()); 941 + let push_result = push(().unwrap().lock().unwrap()); | error[E0425]: cannot find function `pull` in module `pass` --> src/main.rs:953:19 | 953 | let _ = pass::pull(().unwrap().lock().unwrap()) | not found in `pass` | help: consider importing this function | 18 + use ripasso::git::pull; | help: if you import `pull`, refer to it directly | 953 - let _ = pass::pull(().unwrap().lock().unwrap()) 953 + let _ = pull(().unwrap().lock().unwrap()) | error[E0603]: function `init_git_repo` is private --> src/wizard.rs:32:26 | 32 | let init_res = pass::init_git_repo(::password_dir(password_store_dir, home).unwrap()); | ^ private function | note: the function `init_git_repo` is defined here --> /usr/share/cargo/registry/ripasso-0.6.4/src/pass.rs:34:60 | 34 | add_and_commit_internal, commit, find_last_commit, init_git_repo, match_with_parent, |^ I tried to update ripasso-cursive to 0.6.4 to match ripasso but I got. Applying patch unbreak-new-user-wizard.patch patching file src/main.rs Hunk #1 succeeded at with fuzz 1 (offset -58 lines). Hunk #2 FAILED at 1189. Hunk #3 succeeded at 1324 with fuzz 1 (offset 109 lines). Hunk #4 FAILED at 1773. Hunk #5 FAILED at 1789. Hunk #6 FAILED at 1798. Hunk #7 succeeded at 1849 with fuzz 2 (offset 43 lines). 4 out of 7 hunks FAILED -- rejects in file src/main.rs Patch unbreak-new-user-wizard.patch does not apply (enforce with -f) Can someone confirm whether this patch is still needed, and if-so update it for the new upstream version? For what it's worth I was able to get a succesful build by. 1. Upgrading ripasso-cursive to 0.6.3 (0.6.4 has a new dependency that is not in Debian) 2. Disabling unbreak-new-user-wizard.patch and translation-locations.patch I would still like feedback from Alexander on whether those patches are still relavent.
