Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-24 07:52:37 +0100, Andreas Tille wrote: > Am Tue, Nov 22, 2022 at 08:54:13PM +0100 schrieb Andreas Tille: > > If I understood that BioConductor packages should not block other > > transitions. I've just pinged ftpmaster on IRC to check packages > > r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. > > The following packages are blocked by the packages in new: > > > >r-bioc-bitseq - should be removed from testing immediately bug just > > filed) > >r-bioc-multiassayexperiment > >r-bioc-demixt (bug #1024597 was just filed) > >r-bioc-scater > >r-bioc-mofa (just due dependencies) > > > > Do you want me to file RC bugs against r-bioc-multiassayexperiment, > > r-bioc-scater and r-bioc-mofa. > > Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and > r-bioc-singler[2] probably also these two packages need a RC bug to not > block the transition. > > The test suite issue of r-bioc-structuralvariantannotation is discussed > with upstream[4]. I'm fine to remove it from testing for the moment as > well. > > Just let me know whether I should file the according bugs. Please do. Cheers -- Sebastian Ramacher
Bug#1024743: golang-github-tailscale-tscert -- Minimal library implementing parts of the Tailscale client API
Package: wnpp Severity: wishlist Owner: Peymaneh * Package name: golang-github-tailscale-tscert Version : 0.0~git20220316.54bbcb9-1 Upstream Author : Tailscale * URL : https://github.com/tailscale/tscert * License : BSD-3-clause Programming Lang: Go Description : Minimal library for implementing parts of the Tailscale client API This is a stripped down version of the tailscale.com/client/tailscale Go package but with minimal dependencies and supporting older versions of Go. This package is required for packaging Caddy >=2.5.0 OpenPGP_signature Description: OpenPGP digital signature
Bug#1024742: ITP: golang-github-blackfireio-osinfo -- Go library to identify the underlying operating system
Package: wnpp Severity: wishlist Owner: Cyril Brulebois * Package name: golang-github-blackfireio-osinfo Version : 1.0.3-1 Upstream Author : Blackfire * URL : https://github.com/blackfireio/osinfo * License : Expat Programming Lang: Go Description : Go library to identify the underlying operating system This package provides a cross-platform way to identify the operating system some Go code is running on. . The OSInfo structure makes the following fields available: Family, Architecture, ID, Name, Codename, Version, Build. This is part of the last 4 packages required by the crowdsec 1.4.2 release. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1024741: ITP: golang-github-ivanpirog-coloredcobra -- colorize the text output of the Cobra library (library)
Package: wnpp Severity: wishlist Owner: Cyril Brulebois * Package name: golang-github-ivanpirog-coloredcobra Version : 1.0.1-1 Upstream Author : Ivan Pirog * URL : https://github.com/ivanpirog/coloredcobra * License : Expat Programming Lang: Go Description : colorize the text output of the Cobra library (library) The Cobra library makes it possible to create powerful modern CLI but doesn't support color settings for console output. ColoredCobra is a small library to colorize the text output of the Cobra library, making the console output look better. This is part of the last 4 packages required by the crowdsec 1.4.2 release. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1024740: ITP: golang-github-aquasecurity-table -- tables for terminals, in Go (library)
Package: wnpp Severity: wishlist Owner: Cyril Brulebois * Package name: golang-github-aquasecurity-table Version : 1.8.0-1 Upstream Author : Aqua Security * URL : https://github.com/aquasecurity/table * License : Expat Programming Lang: Go Description : tables for terminals, in Go (library) This is a Go module for rendering tables in the terminal, featuring: - Headers/footers - Text wrapping - Auto-merging of cells - Customisable line/border characters - Customisable line/border colours - Individually enable/disable borders, row lines - Set alignments on a per-column basis, with separate - Settings for headers/footers - Intelligently wrap/pad/measure ANSI coloured input - Support for double-width unicode characters - Load data from CSV files This is part of the last 4 packages required by the crowdsec 1.4.2 release. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1
This seems related: https://bugs.debian.org/1024701 Regards signature.asc Description: This is a digitally signed message part
Bug#977739: progress of golang-github-texttheater-golang-levenshtein packaging
Hi Richard, ChangZhuo Chen (2022-06-26): > What is the progress of golang-github-texttheater-golang-levenshtein > packaging, do you need any help on packaging? > > We are working on dyff (https://bugs.debian.org/1013751), and > golang-github-texttheater-golang-levenshtein is in dyff dependency. This ITP has been opened close to two years ago, and we haven't heard back in the last 5 months about possible progress. Since the packaging is rather straightforward, I'm tempted to “steal” this ITP and just upload the package I've prepared locally (required for crowdsec 1.4.2). ChangZhuo Chen, I see you have created a repository on Salsa[1], but the debian/sid branch doesn't contain any debian/ directory at this point, do I have your permission to push my work in this repository, force pushing if required? 1. https://salsa.debian.org/go-team/packages/golang-github-texttheater-golang-levenshtein/-/tree/debian/sid/ Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1023731: BioC Transition blocked by new dependencies
Am Tue, Nov 22, 2022 at 08:54:13PM +0100 schrieb Andreas Tille: > If I understood that BioConductor packages should not block other > transitions. I've just pinged ftpmaster on IRC to check packages > r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. > The following packages are blocked by the packages in new: > >r-bioc-bitseq - should be removed from testing immediately bug just filed) >r-bioc-multiassayexperiment >r-bioc-demixt (bug #1024597 was just filed) >r-bioc-scater >r-bioc-mofa (just due dependencies) > > Do you want me to file RC bugs against r-bioc-multiassayexperiment, > r-bioc-scater and r-bioc-mofa. Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and r-bioc-singler[2] probably also these two packages need a RC bug to not block the transition. The test suite issue of r-bioc-structuralvariantannotation is discussed with upstream[4]. I'm fine to remove it from testing for the moment as well. Just let me know whether I should file the according bugs. Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-bluster/28612583/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-singler/28612594/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-structuralvariantannotation/28615556/log.gz [4] https://lists.debian.org/debian-r/2022/11/msg00067.html -- http://fam-tille.de
Bug#1024739: nmu: libmcfp_1.2.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, I want to request binNMU on amd64 for recently accepted new package. nmu libmcfp_1.2.2-1 . amd64 . unstable . -m "Rebuild on buildd" Thanks, Andrius
Bug#1016881: Please update chrome-gnome-shell to version 42
On Sat, 24 Sep 2022 12:39:08 +0200 =?utf-8?q?Cl=C3=A9ment_Hermann?= wrote: > Package: chrome-gnome-shell > Version: 10.1-5 > Followup-For: Bug #1016881 > > Hi, > > Not sure it's actually a bug on chrome-gnome-shell, since what we need > is a new package that will replace this one for gnome >=42. chrome-gnome-shell should probably turn into an empty package that depends on gnome-browser-extension (once it's uploaded). It would be good to get this done before bookworm freezes. > > The bug here is it should depends on gnome-shell <42.0, I guess. > > RFP for gnome-browser-extension: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020616 > I guess if no one else does it, I'll do it?
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Hi Kevin, On Mon, Nov 21, 2022 at 04:49:16PM -0500, Kevin P. Fleming wrote: > On Sun, Nov 20, 2022, at 12:56, Kevin P. Fleming wrote: > > On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote: > > > >> If that would be helpful, we have some instructions on "simple > >> patching and building" the kernel with a additional patches on top > >> here: > >> > >> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > > > I found those via another path, and used them :-) Had a few little > > issues along the way: failing to set DEBFULLNAME produces a broken > > changelog entry so then the build won't run (and leaves the tree in a > > broken state as well). Once I solved that problem I was able to make > > packages, but the linux-headers-common package didn't get produced, so > > I had to use --force-depends-version when installing the packages > > (which I knew was safe since the headers had not changed). > > > > I now have the patched kernel in operation and should know whether the > > problem is solved in 24-48 hours. > > It's been more than 24 hours and connectivity is still in place, and > it never lasted this long without the patch. I'm comfortable saying > that this patch resolved the problem. Thanks for testing. I will try to make it included in the next unstable upload (waiting for 6.0.10 which should come around friday). Regards, Salvatore
Bug#1013092: ITP: python3-sphinx-autosummary-accessors -- sphinx autosummary extension to pandas or xarray accessors
Dear Diane, On Thu, 16 Jun 2022 13:32:58 -0700 Diane Trout wrote: Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: python3-sphinx-autosummary-accessors Version : 2022.4.0-1 Upstream Author : Justus Magin * URL or Web page : https://github.com/xarray-contrib/sphinx-autosummary-accessors * License : MIT Description : sphinx autosummary extension to pandas or xarray accessors This is a new dependency for building the documentation for dask. One confusing issue is the project is marked as being MIT licensed, but includes the pandas BSD-3 license because some of this project was derived from pandas. Unfortunately there's nothing that says what files were derived from pandas. So my copyright file marks everything as MIT / Expat, but includes the pandas BSD license block though I don't know what to attach it to. I was planning on adding this to the debian python team. Diane Trout This package is also needed for new version of dask. I'm interested in having it in the archive so I would like to know what is the status of this package. Do you already have some work done? Is there anything I can do to help? kind regards -- Antonio Valentino
Bug#1024738: apache-jena: CVE-2022-45136
Source: apache-jena Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi Java maintainers, there is the following vulnerability was published for apache-jena, but there is only little information available. My undestanding is that it still affected 3.17.0, but is it resolved in 4.5.0-1 as it is currently in unstable? [2] at least would indicate it is unpatched yet. CVE-2022-45136[0]: | ** UNSUPPORTED WHEN ASSIGNED ** Apache Jena SDB 3.17.0 and earlier is | vulnerable to a JDBC Deserialisation attack if the attacker is able to | control the JDBC URL used or cause the underlying database server to | return malicious data. The mySQL JDBC driver in particular is known to | be vulnerable to this class of attack. As a result an application | using Apache Jena SDB can be subject to RCE when connected to a | malicious database server. Apache Jena SDB has been EOL since December | 2020 and users should migrate to alternative options e.g. Apache Jena | TDB 2. 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-2022-45136 https://www.cve.org/CVERecord?id=CVE-2022-45136 [1] https://www.openwall.com/lists/oss-security/2022/11/14/5 [2] https://github.com/advisories/GHSA-g2qw-6vrr-v6pq Regards, Salvatore
Bug#1024737: tiff: CVE-2022-3970: TIFFReadRGBATileExt(): fix (unsigned) integer overflow on strips/tiles > 2 GB
Source: tiff Version: 4.4.0-5 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for tiff. CVE-2022-3970[0]: | A vulnerability was found in LibTIFF. It has been classified as | critical. This affects the function TIFFReadRGBATileExt of the file | libtiff/tif_getimage.c. The manipulation leads to integer overflow. It | is possible to initiate the attack remotely. The exploit has been | disclosed to the public and may be used. The name of the patch is | 227500897dfb07fb7d27f7aa570050e62617e3be. It is recommended to apply a | patch to fix this issue. The identifier VDB-213549 was assigned to | this vulnerability. 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-2022-3970 https://www.cve.org/CVERecord?id=CVE-2022-3970 [1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53137 [2] https://gitlab.com/libtiff/libtiff/-/commit/227500897dfb07fb7d27f7aa570050e62617e3be Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1024736: node-xmldom: CVE-2022-39353
Source: node-xmldom Version: 0.8.3-1 Severity: important Tags: security upstream Forwarded: https://github.com/jindw/xmldom/issues/150 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for node-xmldom. CVE-2022-39353[0]: | xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) | `DOMParser` and `XMLSerializer` module. xmldom parses XML that is not | well-formed because it contains multiple top level elements, and adds | all root nodes to the `childNodes` collection of the `Document`, | without reporting any error or throwing. This breaks the assumption | that there is only a single root node in the tree, which led to | issuance of CVE-2022-39299 as it is a potential issue for dependents. | Update to @xmldom/xmldom@~0.7.7, @xmldom/xmldom@~0.8.4 (dist-tag | latest) or @xmldom/xmldom@=0.9.0-beta.4 (dist-tag next). As a | workaround, please one of the following approaches depending on your | use case: instead of searching for elements in the whole DOM, only | search in the `documentElement`or reject a document with a document | that has more then 1 `childNode`. 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-2022-39353 https://www.cve.org/CVERecord?id=CVE-2022-39353 [1] https://github.com/jindw/xmldom/issues/150 [2] https://github.com/xmldom/xmldom/security/advisories/GHSA-crh6-fp67-6883 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1024635: dash: segfaults during runtime when executing a script with invalid syntax
Just for the records, the same issue (as well as some other variant) also exists in other ash bashed shells: klibc: https://lists.zytor.com/archives/klibc/2022-November/004694.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024735 busybox: http://lists.busybox.net/pipermail/busybox/2022-November/090036.html Cheers, Chris.
Bug#1024735: klibc-utils: klibc sh segfault on invalid substitutions
Package: klibc-utils Version: 2.0.11-1 Severity: normal Tags: upstream Hey there. There’s a bug in ash-bashed shells, including the one shipped with klibc. The original variant is described here (for dash): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024635 respectively https://lore.kernel.org/dash/b2e298215b3d51d8284296484caa138faddaa0e4.ca...@scientia.org/ Apparently BusyBox’ sh (also ash based) doesn't segfault on the example I've found above. But Harald van Dijk was able to create an example where BusyBox’ sh segfaults, too, reported: http://lists.busybox.net/pipermail/busybox/2022-November/090036.html klibc’s sh segfaults in BOTH cases. I'll also post this to the upstream mailing list and set it as forwarded here afterwards. Thanks, Chris.
Bug#1020710: RFP: flycheck-grammalecte -- Adds support for Grammalecte (a french grammar checker) to flycheck.
On 2022-09-26 19:03:41, Nicholas D. Steeves wrote: > Please ping me about this in a month, and hopefully I'll have time and > motivation then :) Ping! :) -- If Christ were here there is one thing he would not be -- a Christian. - Mark Twain
Bug#1024734: pipewire-pulse: please enable auto switch on connect in pipewire-pulse.conf by default
Package: pipewire-pulse
Version: 0.3.60-2
Severity: wishlist
Dear Maintainer,
* What led up to the situation?
I connected my already paired headset to my machine.
* What exactly did you do (or not do) that was effective (or
ineffective)?
It connected without error
* What was the outcome of this action?
Chrome was not outputting any sound to my bluetooth headset
* What outcome did you expect instead?
I expect sound should have been directed from chrome to my headset
automatically after my headset connects to the computer.
I eventually found that I could manually switch output using Pulse
Volume control. It would be better to automatically switch when the bt
device connects.
See
https://alexandra-zaharia.github.io/posts/fix-disabled-a2dp-profile-for-bluetooth-headset-in-linux/
Fix involves adding "{ path = "pactl" args = "load-module
module-switch-on-connect" }"
to the /usr/share/pipewire/pipewire-pulse.conf file
Please consider making this the default
Thanks
Jason
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 pipewire-pulse depends on:
ii init-system-helpers 1.65.2
ii pipewire 0.3.60-2
Versions of packages pipewire-pulse recommends:
ii pulseaudio-utils 16.1+dfsg1-2+b1
Versions of packages pipewire-pulse suggests:
ii libspa-0.2-bluetooth 0.3.60-2
-- no debconf information
--
Jason Lewis
http://emacstragic.net
Bug#1024727: firefox-esr: does not support IPv6
Mike Hommey dixit: >Neither Chromium nor Firefox currently implement RFC6874. That’s the point of this bugreport. It works in lynx, but lynx was not sufficient to configure this picky network device. The link-local IP address was the only way to reach it without a full factory reset, due to… reasons. This cost quite some effort. bye, //mirabilos PS: And the % is unencoded. -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Bug#1024733: timeshift: GUI crashes on backup/restore. Fixed upstream, package needs update
Package: timeshift Version: 22.06.5-1 Severity: important X-Debbugs-Cc: mcar...@yahoo.co.uk Dear Maintainer, The GUI crashes on backup or restore with Timeshift v22.06.5. See https://github.com/linuxmint/timeshift/issues/91. Bug is fixed in latest version of Timeshift. Please upgrade this package to a newer version. -- System Information: Debian Release: bookworm/sid APT prefers kinetic-updates APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 'kinetic'), (100, 'kinetic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-23-generic (SMP w/8 CPU threads; PREEMPT) 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 timeshift depends on: ii cron [cron-daemon] 3.0pl1-137ubuntu3 ii libc62.36-0ubuntu4 ii libcairo21.16.0-5ubuntu2 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libgee-0.8-2 0.20.6-1 ii libglib2.0-0 2.74.0-3 ii libgtk-3-0 3.24.34-3ubuntu2 ii libjson-glib-1.0-0 1.6.6-1build1 ii libvte-2.91-00.70.0-1 ii libxapp1 2.2.15-1 ii psmisc 23.5-3 ii rsync3.2.5-1 timeshift recommends no packages. timeshift suggests no packages. -- no debconf information
Bug#1023149: pandoc: diff for NMU version 2.17.1.1-1.1
On Sat, 19 Nov 2022, Adrian Bunk wrote: Control: tags 1023149 + patch Control: tags 1023149 + pending Dear maintainer, I've prepared an NMU for pandoc (versioned as 2.17.1.1-1.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. Can this NMU be accepted ASAP? Assuming I'm reading excuses correctly, I believe this is preventing a massive number of haskell packages from migrating to testing. Thanks, Scott
Bug#1009118: [Debian-med-packaging] Bug#1009118: python3-biopython: incompatible with muscle >= 5
Hello everybody, I have read the Muscle5 paper and it is a totally different program than Muscle3. https://pubmed.ncbi.nlm.nih.gov/36379955/ Reintroducing muscle3 as a separate package might be useful not only to Biopython, but also to the people who need it in pipelines, etc. Have a nice day, Charles
Bug#1024727: firefox-esr: does not support IPv6
forwarded 1024727 https://bugzilla.mozilla.org/show_bug.cgi?id=700999 title 1024727 Firefox does not support ipv6 link-local addresses with severity 1024727 normal thanks On Thu, Nov 24, 2022 at 01:08:19AM +, Thorsten Glaser wrote: > Mike Hommey dixit: > > >> >Try removing that %eth0 from the ipv6 address. > >> > >> That would invalidate said address and is therefore impossible. > > > >Why would it? Is your setup so complex that the network stack can't find > >the right interface to send packets through? > > It’s a link-local address. These do by definition need the interface > specified because they aren’t global. and yet e.g. ping6 is happy with just the IP without the zone-id. > Please do read up on IPv6 basics when commenting on IPv6 specifics… Here's some reading for yourself: - https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c17 - https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2 Neither Chromium nor Firefox currently implement RFC6874. Mike
Bug#1024732: python3-pylibdmtx: The decode procedure truncates the decoded byte-string at null character
Package: python3-pylibdmtx
Version: 0.1.10-1
Severity: important
Dear Maintainer,
I use libdtmx to place 2D codes with compressed and encrypted (and
therefore binary) content.
I have found that the decode routine truncates the decoded content at
the first null byte.
It seems that it incorrectly uses C-strings to pass the data between the
library and Python.
The dmtxread utility correctly decodes such contents.
I send the demonstrator files:
1) demo.png - the 2D code with binary content containing a null byte in
the middle,
2) demo_bug.py - the Python scripts, which decodes only 37 bits (run it
and it will produce the 37 bit long demo_out_0.bin)
If you run:
dmtxread demo.png > demo_ok.bin
you'll get the 111 bytes long demo_ok.bin with correctly decoded data.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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-pylibdmtx depends on:
ii libdmtx0b 0.7.5-3+b1
ii python3 3.10.6-1
ii python3-pil 9.2.0-1.1+b1
python3-pylibdmtx recommends no packages.
python3-pylibdmtx suggests no packages.
-- no debconf information
#!/usr/bin/python
from pylibdmtx.pylibdmtx import decode
from PIL import Image
# Read the scanned test
img = Image.open("demo.png")
if img.mode != 'RGB':
img = img.convert('RGB')
# The timeout value (and other options) below may need adjustment
# If you know any better way how to reasonable control
# precision of the dmtx decoding, please let me know
dm_read=decode(img)
for i in range(0,len(dm_read)):
fout="demo_out_"+str(i)+".bin"
with open(fout,"wb") as fo:
fo.write(dm_read[i].data)
Bug#1024731: python3-pylibdmtx: The decode procedure truncates the decoded byte-string at null character
Package: python3-pylibdmtx
Version: 0.1.10-1
Severity: important
Dear Maintainer,
I use libdtmx to place 2D codes with compressed and encrypted (and
therefore binary) content.
I have found that the decode routine truncates the decoded content at
the first null byte.
It seems that it incorrectly uses C-strings to pass the data between the
library and Python.
The dmtxread utility correctly decodes such contents.
I send the demonstrator files:
1) demo.png - the 2D code with binary content containing a null byte in
the middle,
2) demo_bug.py - the Python scripts, which decodes only 37 bits (run it
and it will produce the 37 bit long demo_out_0.bin)
If you run:
dmtxread demo.png > demo_ok.bin
you'll get the 111 bytes long demo_ok.bin with correctly decoded data.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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-pylibdmtx depends on:
ii libdmtx0b 0.7.5-3+b1
ii python3 3.10.6-1
ii python3-pil 9.2.0-1.1+b1
python3-pylibdmtx recommends no packages.
python3-pylibdmtx suggests no packages.
-- no debconf information
#!/usr/bin/python
from pylibdmtx.pylibdmtx import decode
from PIL import Image
# Read the scanned test
img = Image.open("demo.png")
if img.mode != 'RGB':
img = img.convert('RGB')
# The timeout value (and other options) below may need adjustment
# If you know any better way how to reasonable control
# precision of the dmtx decoding, please let me know
dm_read=decode(img)
for i in range(0,len(dm_read)):
fout="demo_out_"+str(i)+".bin"
with open(fout,"wb") as fo:
fo.write(dm_read[i].data)
Bug#1024727: firefox-esr: does not support IPv6
Mike Hommey dixit: >> >Try removing that %eth0 from the ipv6 address. >> >> That would invalidate said address and is therefore impossible. > >Why would it? Is your setup so complex that the network stack can't find >the right interface to send packets through? It’s a link-local address. These do by definition need the interface specified because they aren’t global. Please do read up on IPv6 basics when commenting on IPv6 specifics… bye, //mirabilos -- 21:12⎜ sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜ linux war früher auch mal besser :D
Bug#1024730: net-tools: Drop DECnet support
Package: net-tools Version: 1.60+git20181103.0eebece-1 Severity: important Control: block 1021094 by -1 Please drop libdnet-dev from net-tools' Build-Depends so that it can be removed from the archive. Kernel support will be removed from Linux 6.1. The package keeps building without that B-D.
Bug#1024727: firefox-esr: does not support IPv6
On Thu, Nov 24, 2022 at 12:00:07AM +, Thorsten Glaser wrote: > Mike Hommey dixit: > > >Try removing that %eth0 from the ipv6 address. > > That would invalidate said address and is therefore impossible. Why would it? Is your setup so complex that the network stack can't find the right interface to send packets through? Mike
Bug#1024729: Upstream library deprecated, replaced by github.com/rabbitmq/amqp091-go
Source: golang-github-streadway-amqp Version: 0.0~git20200716.e6b33f4-3 The upstream library has been deprecated and replaced by github.com/rabbitmq/amqp091-go, soon to be packaged for Debian as golang-github-rabbitmq-amqp091-go. We should work on updating the handful of rdeps to switch to the maintained library, and then RM this package. > $ build-rdeps golang-github-streadway-amqp-dev > Reverse Build-depends in main: > -- > > balboa > fever > garagemq > golang-github-neowaylabs-wabbit > golang-gocloud > hugo > > Found a total of 6 reverse build-depend(s) for > golang-github-streadway-amqp-dev. signature.asc Description: This is a digitally signed message part
Bug#1021094: dnprogs: obsolete? time to remove?
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: dnprogs -- RoQA; obsolete; orphaned; bad packaging DECnet was dropped from 6.1 rc, so this package should be gone.
Bug#1024727: firefox-esr: does not support IPv6
Mike Hommey dixit:
>Try removing that %eth0 from the ipv6 address.
That would invalidate said address and is therefore impossible.
It works in lynx, if knowing that helps.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh"). [aus dasr]
Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules
|On Wed, 9 Nov 2022 at 16:09, Stefan Kangas wrote:
> In rsyslog 8.2210.0-3, the timestamp format was changed to be high
> precision by default. It now looks like this:
>
> 2022-11-09T15:02:03.157819+01:00
>
> I believe this part of all rules:
>
> ^\w{3} [ :[:digit:]]{11}
>
> Must be changed into something like:
>
> ^[[:digit:]-T:.+]{32}
>
I suggest it needs to keep the 'old' prefix as an alternative - for people
that revert the rsyslog setting and for people who enable checking of the
journal, which uses the old format. so rules need to begin with the form
'^(old|new) ...'
Also we should add NEWS.Debian as this affects all local rules too.
i can submit a patch. but will need the maintainer (Jose) DD to upload.
> I have marked this bug "important" for now, but I'd suggest bumping it
> to "serious" as this seems release-critical to me.
+1 on this being important. im not sure a higher severity is technically
correct. And would it help get it actioned or just result in logcheck being
dropped? i dont want to see the latter.
We now have two important bugs which affect every user of logcheck in
testing. The bookworm freeze is fast approaching...
Jose if you are reading this, how can we help you get these fixed?
Bug#1019554: Anacron update
Hello > Hello> I dont think to request a user action is a fair way to solve the issue. > Update of anacron package should leave the fonctionnality as it is before the > update , that is running > Please consider to solve the upgrade of anacron really. > Best Regards It is running and fixed. This only impacted a small number of testing users who upgraded to -33 where symlinks were removed. Anyone who did not update to this version (-33) would not have these issues. Trying to override dh functionality is what caused this problem. I don't think there needs to be more work done. Lance Lin I do not think it is a good idea to leave the package as is for users who were affected without a postinst script that makes sure the service is enabled, if upgraded from versions -33 to -35. I had to specifically look for this bug reports for anacron to make sure the system behaviour is "by design" and anacron service is disabled for some specific purpose. I know where to look for these bug reports and how to fix it, but many people do not and leaving them like that without working cron subsystem is not fair. Thank you Tim
Bug#1024728: ITP: golang-github-rabbitmq-amqp091-go -- Go client for AMQP 0.9.1
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-rabbitmq-amqp091-go Version : 1.5.0-1 Upstream Author : RabbitMQ * URL : https://github.com/rabbitmq/amqp091-go * License : BSD-2-clause Programming Lang: Go Description : Go client for AMQP 0.9.1 This is a Go AMQP 0.9.1 client maintained by the RabbitMQ core team. It was originally developed by Sean Treadway. . The library provides a functional interface that closely represents the AMQP 0.9.1 model targeted to RabbitMQ as a server. This includes the minimum necessary to interact the semantics of the protocol. This library is a dependency for updating golang-github-openzipkin- zipkin-go. It was forked from the now unmaintained library github.com/streadway/amqp (currently packaged in Debian as golang- github-streadway-amqp. It will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1024727: firefox-esr: does not support IPv6
On Thu, Nov 24, 2022 at 12:06:06AM +0100, Thorsten Glaser wrote: > Package: firefox-esr > Version: 102.5.0esr-1~deb11u1 > Severity: serious > Justification: violates a Debian Etch release goal > X-Debbugs-Cc: t...@mirbsd.de > > see attached screenshot Try removing that %eth0 from the ipv6 address.
Bug#1020851: elpa-ement: fails to install along emacs
Hello, Le mercredi 23 novembre 2022 à 14:00, Sean Whitton a écrit : elpa-transient isn't a transitional package -- we'll keep it in Debian even after Emacs 28 is the only Emacs we have. This is because we might need a newer version of transient available for another package. So far our strategy has been to handle this in the code in dh_elpa that generates dependencies, and also not worry about it too much, unless we get a combination that results in something not having its dependency available. I don't think we should be adding Provides/Breaks anywhere without considering corresponding changes in dh_elpa. The change we have used previously was to add the package in question (then org, in the present case transient) to the list of separately packaged libraries in the dhelpa-filter-deps-for-debian. This would create a hard dependency on elpa-transient, regardless of the available version of the same library in the bundled version of emacs. This would solve the problem of elpa-ement and elpa-snakemake. However, this packaged version of elpa-transient would also shadow the transient shipped with emacs, regardless of their respective versions. The use of the Provides: mechanism proposed by Mr. Beckmann on the emacs-common package (which is independent from the changes made in dh-elpa that would need to be done anyway) would prevent that, and also allow apt to save installing a package (elpa-transient) only when the emacs-common version is high enough. This would only require computing, for each elisp libraries shipped with emacs that we also package separately, the version provided by the current version of emacs. A corresponding versioned Provides: field would be then added to emacs-common. I.E. a loop around something like this : (package-desc-version (cadr (assq 'transient package-alist))) This is in fact a simpler and more elegant solution than the one I proposed in 87h6zai8qp.fsf@EBx360. Best, Aymeric
Bug#1024727: firefox-esr: does not support IPv6
Package: firefox-esr Version: 102.5.0esr-1~deb11u1 Severity: serious Justification: violates a Debian Etch release goal X-Debbugs-Cc: t...@mirbsd.de see attached screenshot -- Package-specific info: -- Addons package information -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libasound2 1.2.4-1.1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u5 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.24-0+deb11u1 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii procps 2:3.3.17-5 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.5-0+deb11u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix pn libcanberra0 ii libgssapi-krb5-2 1.18.3-6+deb11u3 pn pulseaudio -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/firefox-esr/browser/omni.ja (from firefox-esr package) debsums: changed file /usr/lib/firefox-esr/omni.ja (from firefox-esr package)
Bug#1007509: dhcp-helper: please consider upgrading to 3.0 source format
I have uploaded a NMU to fix this. debdiff attached.diff -Nru dhcp-helper-1.2/debian/changelog dhcp-helper-1.2/debian/changelog --- dhcp-helper-1.2/debian/changelog2021-01-03 21:26:06.0 +0100 +++ dhcp-helper-1.2/debian/changelog2022-11-23 23:52:28.0 +0100 @@ -1,20 +1,27 @@ +dhcp-helper (1.2-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Convert to 3.0 source format. (closes: #953596, #1007509) + + -- Bastian Germann Wed, 23 Nov 2022 23:52:28 +0100 + dhcp-helper (1.2-3) unstable; urgency=low * Provide build-arch and build-indep targets in rules. (closes: #999149) - + -- Simon Kelley Mon, 3 Jan 2021 20:26:06 + dhcp-helper (1.2-2) unstable; urgency=low * Move PIFfile to /run in systemd service file. (closes: #962204) - + -- Simon Kelley Fri, 26 Jun 2020 20:26:06 + dhcp-helper (1.2-1) unstable; urgency=low * New upstream. * Add systemd unit file. - + -- Simon Kelley Wed, 26 Jun 2015 20:40:36 + dhcp-helper (1.1-3) unstable; urgency=low @@ -35,7 +42,7 @@ * Use dpkg-buildflags. * Update conflicts to include isc-dhcp-server and isc-dhcp-relay. * Bump Standards-version to 3.9.3 - + -- Simon Kelley Wed, 26 Jun 2012 20:40:36 + dhcp-helper (1.0-1) unstable; urgency=low @@ -71,41 +78,31 @@ * New upstream. * Bumped standards-version (no changes required). - + -- Simon Kelley Thur, 4 May 2006 15:28:33 +0100 dhcp-helper (0.5-1) unstable; urgency=low * New upstream. - + -- Simon Kelley Fri, 23 Mar 2006 17:58:43 +0100 dhcp-helper (0.4-1) unstable; urgency=low * New upstream. * Removed postints bashism. - + -- Simon Kelley Fri, 17 Mar 2006 20:20:20 +0100 - + dhcp-helper (0.3-1) unstable; urgency=low * Bumped release to mark tweaks to packaging in preparation * for entry into Debian proper. (closes: #320492) - + -- Simon Kelley Sun, 31 Jul 2005 10:15:20 +0100 dhcp-helper (0.2-1) unstable; urgency=low * Initial version - - -- Simon Kelley Mon, 29 Nov 2004 20:27:27 + - - - - - - - - - + -- Simon Kelley Mon, 29 Nov 2004 20:27:27 + diff -Nru dhcp-helper-1.2/debian/source/format dhcp-helper-1.2/debian/source/format --- dhcp-helper-1.2/debian/source/format2021-01-03 21:26:06.0 +0100 +++ dhcp-helper-1.2/debian/source/format2022-11-23 23:52:28.0 +0100 @@ -1 +1 @@ -1.0 +3.0 (quilt)
Bug#1009118: python3-biopython: incompatible with muscle >= 5
Hi all,
Andrius Merkys, on 2022-10-17:
> On 2022-10-13 14:31, Andreas Tille wrote:
> > > On Thu, 7 Apr 2022 15:44:43 +0300 Andrius Merkys
> > > wrote:
> > > > python3-biopython is incompatible with muscle >= 5.
> > > I tend to think this is serious-ish as biopython integration with muscle
> > > from Debian package will not work. Upstream has been notified [1] and
> > > their
> > > response was to drop all wrappers at some point. However, it becomes clear
> > > that this point is beyond the bookworm's freeze (June 2022, to cite
> > > upstream), thus we are at risk of shipping a broken package.
> > >
> > > What should we do?
> > >
> > > B. Patch biopython to detect muscle >= 5 and throw an error?
> > >
> > > C. Slap a warning (debian/NEWS) that biopython interface with muscle >=5
> > > is
> > > broken and should only be used with local installations of muscle <5?
> >
> > I think both B+C is a sensible way to simply set bug #1009118 wishlist
> > to give room for A anyway.
>
> I agree this would make biopython fit to release in bookworm.
I implemented B by checking for "muscle 5" in --version output.
Attempt to make use of such muscle version with biopython would
end up with a RuntimeError, for example:
Traceback (most recent call last):
File
"/<>/.pybuild/cpython3_3.11/build/Tests/test_Muscle_tool.py", line
197, in test_simple_msf
cmdline = MuscleCommandline(muscle_exe, input=input_file, msf=True)
^
File
"/<>/.pybuild/cpython3_3.11/build/Bio/Align/Applications/_Muscle.py",
line 682, in __init__
raise RuntimeError("muscle 5 is unsupported in biopython")
RuntimeError: muscle 5 is unsupported in biopython
I also implemented C with the following NEWS item:
python-biopython (1.80+dfsg-1) experimental; urgency=medium
Starting with biopython 1.79, command wrappers are being deprecated,
and may be removed past biopython 1.81. This has the notable
implication that support of the muscle command past version 5 has
never been implemented, and probably will never be[1,2].
Users of muscle are invited either to use a generic command launcher
such as the module "subprocess", or to stick to muscle 3.
[1]: https://github.com/biopython/biopython/issues/3902
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009118
-- Étienne Mollier Wed, 23 Nov 2022 23:19:22 +0100
I tried to keep messages succinct, but if you think this is too
terse, improvements are welcome.
Have a nice day, :)
--
.''`. Étienne Mollier
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`-
signature.asc
Description: PGP signature
Bug#1023580: A recent Bookworm upgrade broke video playback in the VLC player
On Sun, 13 Nov 2022 at 14:00, Alexis Murzeau wrote: > > Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-108407 > > On 12/11/2022 19:02, Alexis Murzeau wrote: > > On 11/11/2022 21:50, Alexis Murzeau wrote: > >> > >> I've tried to create a minimal Qt sample application that would reproduce > >> the issue, but I can't get it. > >> Maybe there is something related with a specific feature or configuration. > >> > > > > Instead of trying to create a minimal Qt application that reproduce the > > problem, I've tried to reproduce the issue with rebuilt Qt binaries from > > upstream. > > I'm successfully reproducing the issue with virtualbox and vlc with a Qt > > build of the tag v5.15.6-lts-lgpl but not with a build of v5.15.4-lts-lgpl. > > > > So I'm going to bisect commits to find which one introduced the issue. > > > > I've found the offending commit. > It's 290b405872602de931646fe4f769eff208f9bbef: xcb: implement missing bits > from ICCCM 4.1.4 WM_STATE handling. > > See here: > https://github.com/qt/qtbase/commit/290b405872602de931646fe4f769eff208f9bbef > > It was made to fix https://bugreports.qt.io/browse/QTBUG-69515, but > reverted later in upcoming version 5.15.10. > > I've tested v5.15.6 with this commit reverted, and vlc and virtualbox > doesn't have the issue anymore, so reverting only this commit seems > sufficient to fix this bug. > > Because of 2 regressions bugs, this commit was already reverted in upstream > versions 5.15.10, 6.2.5, 6.3.1 and 6.4.0+ (see "resulted in" in QTBUG-69515). > > > I'm not sure if this bug (affecting vlc and virtualbox) is already known > in this form by upstream, existing upstream bugs only talk about to > window undocking and menus. > > So I've created a bug upstream about it, as this affect popular > applications, to ensure upstream is aware of it: > https://bugreports.qt.io/browse/QTBUG-108407 > > Also as a reference, Debian bug #1022748 is caused by the same commit > 290b405872602de931646fe4f769eff208f9bbef. Excellent job! Do you think you could prepare a MR in salsa.debian.org ? -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1017487: RFP: python-sphinx-design -- Sphinx extension for designing view size-responsive web components
Dear Sandro, On Tue, 16 Aug 2022 18:34:38 -0400 Sandro Tosi wrote: > * Package name: python-sphinx-design > Version : 0.2.0 > Upstream Author : Chris Sewell > * URL : https://github.com/executablebooks/sphinx-design > * License : Expat > Programming Lang: Python > Description : Sphinx extension for designing view size-responsive web components > > The latest upstream version of pikepdf, primarily maintained by me, > requires this library for its docs build. I'd therefore be very > grateful if someone on the Python team would package it. matplotlib is going to depend on this library, so i'll have a look at packaging it. retitle/owner commands coming up -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi This package is also needed to update dask. What is the status? Do you have a prototype already? If you want I could help with it. kind regards -- Antonio Valentino
Bug#1023739: sipsak: Message mode causes segmentation fault
Dear Maintainer, I could reproduce a crash inside a minimal Bookworm/testing amd64 qemu VM. There I took below backtrace [2]. Having msg_data->repl_buff equal NULL seems to be the issue. Upstream commit [1] looks related and a package built with this commit does not crash with the example command. Kind regards, Bernhard [1] https://github.com/nils-ohlmeier/sipsak/commit/8f132bb35b5ce55d76b2e0fc633ad0cc17bbff42 [2] $ rr sipsak -M -B Hi -c sip:benutzer@localhost -s sip:benutzer@localhost rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/sipsak-0'. Speicherzugriffsfehler $ rr replay -o -q ... Program received signal SIGSEGV, Segmentation fault. 0x7fbe6d455096 in __vsprintf_internal (string=0x0, maxlen=maxlen@entry=18446744073709551615, format=0x55e754af5540 "%s%ssip:sipsak@%s:%i;tag=%x\r\n%ssip:%s%s;tag=%o%o\r\n%s%u@%s\r\n%s%i %s\r\n%s0\r\n%s%s\r\n\r\n", args=args@entry=0x7ffc6c063840, mode_flags=mode_flags@entry=6) at iovsprintf.c:88 88 iovsprintf.c: Datei oder Verzeichnis nicht gefunden. (rr) bt #0 0x7fbe6d455096 in __vsprintf_internal (string=0x0, maxlen=maxlen@entry=18446744073709551615, format=0x55e754af5540 "%s%ssip:sipsak@%s:%i;tag=%x\r\n%ssip:%s%s;tag=%o%o\r\n%s%u@%s\r\n%s%i %s\r\n%s0\r\n%s%s\r\n\r\n", args=args@entry=0x7ffc6c063840, mode_flags=mode_flags@entry=6) at iovsprintf.c:88 #1 0x7fbe6d4eba3b in ___sprintf_chk (s=, flag=flag@entry=1, slen=slen@entry=18446744073709551615, format=format@entry=0x55e754af5540 "%s%ssip:sipsak@%s:%i;tag=%x\r\n%ssip:%s%s;tag=%o%o\r\n%s%u@%s\r\n%s%i %s\r\n%s0\r\n%s%s\r\n\r\n") at sprintf_chk.c:40 #2 0x55e754aefb5e in sprintf (__fmt=0x55e754af5540 "%s%ssip:sipsak@%s:%i;tag=%x\r\n%ssip:%s%s;tag=%o%o\r\n%s%u@%s\r\n%s%i %s\r\n%s0\r\n%s%s\r\n\r\n", __s=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:36 #3 create_msg (action=action@entry=4, msg_data=msg_data@entry=0x55e754afd840 ) at src/request.c:227 #4 0x55e754af2b41 in shoot (buf=buf@entry=0x7ffc6c065c10 "MESSAGE sip:benutzer@localhost SIP/2.0\r\nVia: SIP/2.0/UDP 127.0.1.1:59617;branch=z9hG4bK.1a7c9125;rport;alias\r\nTo: sip:benutzer@localhost\r\nCall-ID: 1272641755@127.0.1.1\r\nCSeq: 1 MESSAGE\r\nContent-Type: "..., buff_size=buff_size@entry=4096, options=options@entry=0x7ffc6c065b10) at src/shoot.c:986 #5 0x55e754ae6c12 in main (argc=, argv=) at src/sipsak.c:1044 (rr) up (rr) up (rr) up #3 create_msg (action=action@entry=4, msg_data=msg_data@entry=0x55e754afd840 ) at src/request.c:227 227 sprintf(msg_data->repl_buff, (rr) display/i $pc 1: x/i $pc => 0x55e754aefb5e :add$0x90,%rsp (rr) list 225 } 226 add_via(req_buf_begin, msg_data->fqdn, msg_data->lport); 227 sprintf(msg_data->repl_buff, 228 "%s" 229 "%ssip:sipsak@%s:%i;tag=%x\r\n" 230 "%ssip:%s%s;tag=%o%o\r\n" 231 "%s%u@%s\r\n" 232 "%s%i %s\r\n" 233 "%s0\r\n" 234 "%s%s\r\n" 235 "\r\n", 236 SIP200_STR, 237 FROM_STR, msg_data->fqdn, msg_data->lport, c, 238 TO_STR, msg_data->username, msg_data->domainname, c, d, 239 CALL_STR, c, msg_data->fqdn, 240 CSEQ_STR, msg_data->cseq_counter, MES_STR, 241 CON_LEN_STR, 242 UA_STR, UA_VAL_STR); 243 break; (rr) print msg_data->repl_buff $1 = 0x0
Bug#1021645: bullseye-pu: package postfix/3.5.13-0+deb11u1
On Wednesday, November 23, 2022 3:42:08 PM EST Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2022-10-12 at 00:05 -0400, Scott Kitterman wrote: > > This is another in my occasional series of postfix updates to > > keep up with upstream maintenance updates to the version in > > stable (v3.5). Upstream is still judicious and reasonable in > > their approach to fixing things. The maintenance updates are > > generally suitable for Debian stable updates. > > Please go ahead. Uploaded. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 5:15 PM László Böszörményi (GCS) wrote: > On Wed, Nov 23, 2022 at 6:52 AM tony mancill wrote: > > This issue goes away for me after a rebuild of src:evolution-data-server > > and installing the freshly rebuilt libebook-contacts-1.2-4. > > > > Maybe we can kick off a rebuild via the transition. If not that, would > > you be willing to do a sourceful upload Jeremy? > Just for the record, he asked for a evolution-data-server binNMU [1] > for this issue. No sourceful upload will be needed. Will the evolution-data-server binNMU be held in Unstable until libphonenumber and protobuf migrate to Testing? I don't want to have Testing broken because of this issue either. Thank you, Jeremy Bicha
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 6:52 AM tony mancill wrote: > This issue goes away for me after a rebuild of src:evolution-data-server > and installing the freshly rebuilt libebook-contacts-1.2-4. > > Maybe we can kick off a rebuild via the transition. If not that, would > you be willing to do a sourceful upload Jeremy? Just for the record, he asked for a evolution-data-server binNMU [1] for this issue. No sourceful upload will be needed. Regards, Laszlo/GCS [1] https://bugs.debian.org/1024726
Bug#1024054: bullseye-pu: package mariadb-10.5 10.5.18-0+deb11u1
On Sun, 2022-11-13 at 22:10 -0800, Otto Kekäläinen wrote: > I propose that the latest version of MariaDB 10.5.18 would be > included > in the upcoming stable release update of Debian. Package almost ready > at > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bullseye > > Before I submit the final debdiff and changelog I will wait for the > release date to show up at https://release.debian.org/ > That now happened, fwiw. Regards, Adam
Bug#1023423: bullseye-pu: package pysubnettree/0.33-1
On Wednesday, November 23, 2022 3:55:01 PM EST Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2022-11-03 at 16:32 -0400, Scott Kitterman wrote: > > Package is totally broken in Bullseye (see #1005044) and this fixes > > it. > > Please go ahead. > > Regards, > > Adam Uploaded. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: high Please schedule this rebuild to fix evolution-data-server compatibility with libphonenumber which was rebuilt for the ongoing protobuf transition. This rebuild wasn't on the auto tracker which suggests that there is a bigger dependency issue somewhere. I don't know if other packages are also affected. See https://bugs.debian.org/1024674 Here's my guess at the syntax: nmu evolution-data-server_3.46.1-1+b1 . ANY . unstable . -m "libphonenumber8 (>= 8.12.57+ds-1+b2)" Thanks, Jeremy Bicha
Bug#1024651: ruby-gpgme: FTBFS against libgpgme-dev >= 1.18.0-2
I was hit by this, and created https://github.com/ueno/ruby-gpgme/pull/166. Won't have much time on this topic however.
Bug#1024343: insighttoolkit4: releasability with bookworm?
Control: tags -1 - moreinfo Hi Sebastian, Sorry, I might have triggered the upload a couple of minutes too early. Anyway, thanks for reaching out! Sebastian Ramacher, on 2022-11-23: > On 2022-11-17 21:44:22 +0100, Étienne Mollier wrote: > > However, there are still several reverse dependencies which have > > not made the jump to itk-5.y yet, and are currently out of > > testing due to depending on packages which are not part of the > > testing distribution anymore. Also, I noticed in the RC bug[1] > > affecting it that there has been quite some effort from > > different parties to try to help bringing it back to testing, > > but to no avail. Finally, I had been hoping to keep the library > > in a somewhat working condition for downstream users to be able > > to migrate somewhat smoothly from itk-4.y to itk-5.y in > > bookworm; the latter was not made available in bullseye alas. > > Which of the reverse dependencies do you want to see in bookworm? From > the two of the three I looked at, they have their own RC bugs and look > mostly unmaintained. ants, for example, has a RC bug open from 2017. I've been mostly concerned by the third one, otb[1], which seems still under active maintenance even though it is held by missing ITK4 dependencies. [1]: https://tracker.debian.org/pkg/otb itksnap 4.0.0 is due to support vtk9 and itk5, but looks still under beta release, so didn't make it to the packaging step yet. Looking at reverse build dependencies, facet-analyser looks to have made the move to itk5 recently and shouldn't be in trouble. Things otherwise moved on since last time I checked. Maybe I worry too much. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Camel - Rainbow's End signature.asc Description: PGP signature
Bug#1023413: dh-cargo: should prevent dh_clean from removing Cargo.toml.orig
Control: tags 1023413 + patch
On Sun 2022-11-20 19:03:08 +0100, Niels Thykier wrote:
> As for doing it, you would be adding:
>
> add_command_options('dh_clean', '-XCargo.toml.orig');
>
> (or something along those lines) to the
> Debian/Debhelper/Sequence/cargo.pm file. It would cover the base case
> where people is using dh with the cargo sequence (and is not overriding
> dh_clean - it might also work for overrides, I do not remember).
>
>
> While you are at it, I can recommend adding `Provides:
> dh-sequence-cargo` to the dh-cargo package. This will enable consumers
> to enable the `cargo` sequence by using `Build-Depends:
> dh-sequence-cargo`. Means less boilerplate for them.
Thanks for these suggestions, Niels. I've submitted some patches to
dh-cargo that should resolve the problem over here:
https://salsa.debian.org/rust-team/dh-cargo/-/merge_requests/8
the relevant changeset is included in the attachment below.
--dkg
From df414b1287e8faf8b46f596b7ee5def51fc98dbe Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Wed, 23 Nov 2022 08:29:27 -0500
Subject: [PATCH] Avoid stripping Cargo.toml.orig (Closes: #1023413)
When a Rust crate is published on crates.io, the upstream source
Cargo.toml gets transformed, and the preferred form for editing gets
copied over to Cargo.toml.orig.
Some tooling related to Rust crates (e.g., the document-features
crate) inspects comments in Cargo.toml, which are typically stripped
during the usual transformation, and the only place those comments can
be found is in Cargo.toml.orig.
dh_clean by default strips *.orig, which makes it impossible to use
this kind of tooling. It also means that the original form of
Cargo.toml is deleted each time the package is built.
This change keeps Cargo.toml.orig around for those situations where
it's useful during the crate build.
---
Sequence/cargo.pm | 11 +++
debian/dh-cargo.install | 1 +
2 files changed, 12 insertions(+)
create mode 100644 Sequence/cargo.pm
diff --git a/Sequence/cargo.pm b/Sequence/cargo.pm
new file mode 100644
index 000..22b975c
--- /dev/null
+++ b/Sequence/cargo.pm
@@ -0,0 +1,11 @@
+#!/usr/bin/perl
+# debhelper sequence file for packaging Rust crates with cargo
+
+use warnings;
+use strict;
+use Debian::Debhelper::Dh_Lib;
+
+# See https://bugs.debian.org/1023413
+add_command_options('dh_clean', '-XCargo.toml.orig');
+
+1;
diff --git a/debian/dh-cargo.install b/debian/dh-cargo.install
index 758346f..3a8c779 100644
--- a/debian/dh-cargo.install
+++ b/debian/dh-cargo.install
@@ -1,3 +1,4 @@
+Sequence/cargo.pm/usr/share/perl5/Debian/Debhelper/Sequence/
cargo-auto-test /usr/share/cargo/bin
cargo.pm /usr/share/perl5/Debian/Debhelper/Buildsystem/
dh-cargo-built-using /usr/share/cargo/bin
--
2.35.1
signature.asc
Description: PGP signature
Bug#1024725: RM: futatabi [missing libluajit-5.1-dev] -- ANAIS; ppc64el
Package: ftp.debian.org Severity: normal Hi, futatabi (nageru source package) no longer has ppc64el in its architecture list, since libluajit-5.1-dev does not exist there. This was already fixed for nageru itself, but futatabi has stuck around due to an error. Please rm the binary package so that nageru can transition to testing (fixes an RC bug).
Bug#1024417: [pkg-gnupg-maint] Bug#1024417: kgpg FTBFS: Did not find GPGME
On Wed 2022-11-23 16:27:43 +0100, Andreas Metzler wrote: > Unless kgpg maintainers/upstream has a strong opinion against using > pkg-config the obvious choice would be to drop cmake/FindGpgme.cmake > and simply use FindPkgConfig. - Attached patch seems to work for me, > i.e. build including dh_auto_test works. Thanks for this, Andreas. I've proposed this change upstream as well at https://invent.kde.org/utilities/kgpg/-/merge_requests/18 --dkg signature.asc Description: PGP signature
Bug#1023601: [pkg-gnupg-maint] Bug#1023601: libgpgme-dev: removal of gpgme-config breaks the build of software relying on it
On Wed 2022-11-23 13:20:51 +0100, Andreas Metzler wrote: > On 2022-11-20 Andreas Metzler wrote: >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gpgme-config-transition;users=pkg-gnupg-ma...@lists.alioth.debian.org >> for progressing buglist. > I have now run through all packages with b-d on gpgme and filed bugs. thank you for all this triage, Andreas! This is very helpful work. --dkg signature.asc Description: PGP signature
Bug#1024719: linphone-desktop: New version 5.0 available upstream
X-Debbugs-Cc: Karl Schmidt On Wed, Nov 23, 2022 at 12:21:51PM -0600, Karl Schmidt wrote: > Worth jumping forward to this release.. > [...] > This is version 5.0.0-beta At5.12.12 The transition process to get linphone-desktop 4.4.10 into testing has been initiated already, and since 5.0 is still in beta I see no point in trying to stop it. I'll start work on 5.0 some time after its official release. Regards.
Bug#1024385: bullseye-pu: package openvpn-auth-radius/2.1-7+deb11u1
Control: tags -1 + confirmed On Sat, 2022-11-19 at 01:21 +0800, Shengjing Zhu wrote: > Fix #954264: Support for verify-client-cert openvpn 2.4 directive. > > [ Impact ] > The current version doesn't work with openvpn version (2.5.1) in > stable. > The old workaround only works for openvpn 2.4. > Please go ahead. Regards, Adam
Bug#1023981: bullseye-pu: package onionshare/2.2-3+deb11u1
Control: tags -1 + confirmed On Sun, 2022-11-13 at 14:57 +0100, Clément Hermann wrote: > Following discussion with Security Team about vulnerabilities in > onionshare (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014966 ), I > prepared a > patched version which backport upstream fixes for CVE-2022-21689 and > CVE-2022-21690. > Please go ahead. Regards, Adam
Bug#1023798: Update to fix also CVE-2022-37599
Control: tags -1 + confirmed On Mon, 2022-11-14 at 11:05 +0100, Yadd wrote: > On 14/11/2022 11:01, Yadd wrote: > > Hi, > > > > here is another update to fix CVE-2022-37599 (trivial patch). > > > > Cheers, > > Yadd > > This fix also CVE-2022-37603 (duplicate of CVE-2022-37599) Please go ahead. Regards, Adam
Bug#1020851: elpa-ement: fails to install along emacs
Hello, On Wed 23 Nov 2022 at 01:17PM +01, Andreas Beckmann wrote: > On 23/11/2022 01.11, Sean Whitton wrote: >> Hello, >> On Tue 22 Nov 2022 at 05:39PM +01, Andreas Beckmann wrote: >> >>> On 28/09/2022 16.55, Sean Whitton wrote: transient is included in Emacs 28 so I'm inclined to leave this to fix itself when Emacs 28 migrates. >>> >>> Can't this be expressed as a package relationship? >>> e.g. Depends: emacs-el (>= 1:28) >> It's against the Emacsen Team policy to have a hard dependency on Emacs >> -- instead, it's in Recommends. So I'd prefer not to add a dependency >> that I'm only going to have to remove in a few weeks when Emacs >> migrates. But if you think this bug is getting in the way then I can >> add it. > > There is another occurrence of this bug in elpa-snakemake, #1024648. > Diane made me aware that there is currently a elpa-transient package ... > > Quoting myself what I wrote there: > >> But if emacs-el (or -common?) bundles extensions (or however you call them), >> especially ones that were previously packaged separately, it should probably >> have versioned Provides (and maybe versioned Breaks, too) for >> them. (Cf. perl, perl-base which does the same.) >> Not sure whether these should be in -el or -common ... >> If these Provides were available, elpa-snakemake wouldn't need to know about >> the packaging details of other packages and could just use >> Depends: elpa-transient > > There are a few other packages currently using Depends: elpa-transient elpa-transient isn't a transitional package -- we'll keep it in Debian even after Emacs 28 is the only Emacs we have. This is because we might need a newer version of transient available for another package. So far our strategy has been to handle this in the code in dh_elpa that generates dependencies, and also not worry about it too much, unless we get a combination that results in something not having its dependency available. I don't think we should be adding Provides/Breaks anywhere without considering corresponding changes in dh_elpa. -- Sean Whitton
Bug#1023602: bullseye-pu: package xfig/1:3.2.8-3
Control: tags -1 + confirmed On Mon, 2022-11-07 at 14:16 +0100, Roland Rosenfeld wrote: > This fixes CVE-2021-40241 (a potential buffer overflow in reading an > environment variable). > Please go ahead. Regards, Adam
Bug#1023423: bullseye-pu: package pysubnettree/0.33-1
Control: tags -1 + confirmed On Thu, 2022-11-03 at 16:32 -0400, Scott Kitterman wrote: > Package is totally broken in Bullseye (see #1005044) and this fixes > it. > Please go ahead. Regards, Adam
Bug#1023263: bullseye-pu: package clickhouse/18.16.1+ds-4+deb10u1
Control: tags -1 + confirmed On Tue, 2022-11-01 at 12:24 +0100, Tobias Frost wrote: > I'm currently preparing a security update for clickhouse for LTS. > As the versions are quite similar, I've also prepared an update for > bullseye, > even if the issues are marked "minor". > > The CVE's are: > CVE-2021-42387, CVE-2021-42388, CVE-2021-43304, CVE-2021-43305 > (Details on them are in #1008216) > Please go ahead. Regards, Adam
Bug#1024343: insighttoolkit4: releasability with bookworm?
Control: tags -1 moreinfo On 2022-11-17 21:44:22 +0100, Étienne Mollier wrote: > Package: release.debian.org > Severity: important > X-Debbugs-Cc: debian-...@lists.debian.org > > Dear Release Team, > > I would like to seek advice whether build-depending on gcc-11 > for insighttoolkit4 would be an acceptable tradeoff to maintain > this library in the upcoming bookworm? Even, whether trying to > bring it to bookworm would be acceptable at all? > > The library is not maintained anymore for quite some time, in > favor of it's up-to-date version insighttoolkit5. I also > suspect maintainability of the old version will be a problem > from a security point of view: for instance some un-vendored > libraries went back in the source package after breakages in the > test suite caused by updates in the system libraries. > > However, there are still several reverse dependencies which have > not made the jump to itk-5.y yet, and are currently out of > testing due to depending on packages which are not part of the > testing distribution anymore. Also, I noticed in the RC bug[1] > affecting it that there has been quite some effort from > different parties to try to help bringing it back to testing, > but to no avail. Finally, I had been hoping to keep the library > in a somewhat working condition for downstream users to be able > to migrate somewhat smoothly from itk-4.y to itk-5.y in > bookworm; the latter was not made available in bullseye alas. Which of the reverse dependencies do you want to see in bookworm? From the two of the three I looked at, they have their own RC bugs and look mostly unmaintained. ants, for example, has a RC bug open from 2017. Cheers > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012950 > > Thank you for your effort in coordinating the construction of > Debian releases! > > Have a nice day, :) > -- > .''`. Étienne Mollier > : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > `. `' sent from /dev/tty1, please excuse my verbosity >`-on air: Symphony X - Charon -- Sebastian Ramacher
Bug#1023261: bullseye-pu: package libtasn1-6/4.16.0-2+deb11u1
Control: tags -1 + confirmed On Tue, 2022-11-01 at 12:11 +0100, Andreas Metzler wrote: > I would like to fix CVE-2021-46848 in bullseye. This was fixed in > sid/testing by new upstream 4.19.0. I already had some correspondence > with debian-security, no DSA is planned. > Please go ahead. Regards, Adam
Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
Control: tags -1 + confirmed On Sun, 2022-10-30 at 10:31 +0100, Felix Geyer wrote: > Fixing the no-dsa tagged CVE-2021-42260 > > [ Impact ] > DoS vulnerability > Please go ahead. Regards, Adam
Bug#1022122: bullseye-pu: package node-minimatch/3.0.4+~3.0.3-1+deb11u1
Control: tags -1 + confirmed On Thu, 2022-10-20 at 17:22 +0200, Yadd wrote: > node-minimatch is vulnerable to ReDoS > Please go ahead. Regards, Adam
Bug#1021963: bullseye-pu: package dcfldd/1.7-3+deb11u1
Control: tags -1 + confirmed On Mon, 2022-10-17 at 21:35 -0300, Joao Eriberto Mota Filho wrote: > This is not a regression, but a discovered bug. > > dcfldd is an enhanced dd command that is able to calculate the > following hashes > when copying data: MD5, SHA1 and SHA2. > > The SHA1 was being wrongly calculated on big endian architectures. > Please go ahead. Regards, Adam
Bug#1021838: bullseye-pu: package binfmt-support/2.2.1-1+deb11u1
Control: tags -1 + confirmed On Sat, 2022-10-15 at 18:11 +0100, Colin Watson wrote: > https://bugs.debian.org/1012154 reported a startup issue due to a > race > between systemd-binfmt.service and binfmt-support.service (which has > probably been around for a long time). > https://bugs.debian.org/1021822 > mentions that it would be helpful to have the fix for this in stable > as > well, which I agree with. > > [ Impact ] > binfmt-support.service will sometimes fail to start, so binary format > specifications registered with it may or may not do anything > depending on luck at boot time. > Please go ahead. Regards, Adam
Bug#1021645: bullseye-pu: package postfix/3.5.13-0+deb11u1
Control: tags -1 + confirmed On Wed, 2022-10-12 at 00:05 -0400, Scott Kitterman wrote: > This is another in my occasional series of postfix updates to > keep up with upstream maintenance updates to the version in > stable (v3.5). Upstream is still judicious and reasonable in > their approach to fixing things. The maintenance updates are > generally suitable for Debian stable updates. > Please go ahead. Regards, Adam
Bug#1024724: cargo: FTBFS on armel
Source: cargo
Version: 0.63.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=cargo=armel=0.63.1-2=1668950215=0
failures:
lto::doctest stdout
running `/<>/target/armv5te-unknown-linux-gnueabi/debug/cargo test
--doc --release -v`
thread 'lto::doctest' panicked at '
test failed running
`/<>/target/armv5te-unknown-linux-gnueabi/debug/cargo test --doc
--release -v`
error: process exited with code 101 (expected 0)
--- stdout
running 1 test
test src/lib.rs - foo (line 4) ... FAILED
failures:
src/lib.rs - foo (line 4) stdout
/usr/lib/arm-linux-gnueabi/librustc_driver-fc7fba010be85912.so(+0x4dfaf8)[0xb40efaf8]
/lib/arm-linux-gnueabi/libc.so.6(__default_sa_restorer+0x0)[0xb38d68e0]
Couldn't compile the test.
failures:
src/lib.rs - foo (line 4)
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out;
finished in 28.08s
--- stderr
Compiling bar v0.1.0
(/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/bar)
Running `rustc --crate-name bar bar/src/lib.rs --error-format=json
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib
--emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto -C
metadata=44fca5225a6f9f62 -C extra-filename=-44fca5225a6f9f62 --out-dir
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps`
Compiling foo v0.1.0
(/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo)
Running `rustc --crate-name foo --edition=2018 src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat
--crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C
linker-plugin-lto -C metadata=58c689641ff160d8 -C
extra-filename=-58c689641ff160d8 --out-dir
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps
--extern
bar=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps/libbar-44fca5225a6f9f62.rmeta`
Finished release [optimized] target(s) in 0.79s
Doc-tests foo
Running `rustdoc --edition=2018 --crate-type lib --crate-name foo --test
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/src/lib.rs
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps
--extern
bar=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps/libbar-44fca5225a6f9f62.rlib
--extern
foo=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1506/foo/target/release/deps/libfoo-58c689641ff160d8.rlib
-C lto --error-format human`
error: test failed, to rerun pass '--doc'
', tests/testsuite/lto.rs:722:10
stack backtrace:
0: rust_begin_unwind
at /usr/src/rustc-1.62.1/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /usr/src/rustc-1.62.1/library/core/src/panicking.rs:142:14
2: cargo_test_support::panic_error::pe
at /usr/src/cargo-0.63.1/crates/cargo-test-support/src/lib.rs:66:9
3: cargo_test_support::panic_error
at /usr/src/cargo-0.63.1/crates/cargo-test-support/src/lib.rs:58:5
4: cargo_test_support::Execs::run
at
/usr/src/cargo-0.63.1/crates/cargo-test-support/src/lib.rs:825:13
5: testsuite::lto::doctest
at /usr/src/cargo-0.63.1/tests/testsuite/lto.rs:717:5
6: testsuite::lto::doctest::{{closure}}
at /usr/src/cargo-0.63.1/tests/testsuite/lto.rs:679:1
7: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.62.1/library/core/src/ops/function.rs:248:5
8: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.62.1/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
lto::test_profile stdout
running `/<>/target/armv5te-unknown-linux-gnueabi/debug/cargo test
-v`
thread 'lto::test_profile' panicked at '
test failed running
`/<>/target/armv5te-unknown-linux-gnueabi/debug/cargo test -v`
error: process exited with code 101 (expected 0)
--- stdout
--- stderr
Updating `dummy-registry` index
Downloading crates ...
Downloaded bar v0.0.1 (registry `dummy-registry`)
Compiling bar v0.0.1
Running `rustc --crate-name bar
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1514/home/.cargo/registry/src/-82190a457c441f66/bar-0.0.1/src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat
--crate-type lib --emit=dep-info,metadata,link -C linker-plugin-lto -C
debuginfo=2 -C metadata=17410d84be58d246 -C extra-filename=-17410d84be58d246
Bug#1024712: jhead: New dependency on graphicsmagick-imagemagick-compat
On Wed, 23 Nov 2022 20:16:55 +, Joachim Reichel wrote: > > [...] Now I'm wondering if changing the runtime dependency to > > "graphicsmagick-imagemagick-compat | imagemagick" would achieve the > > same while allowing the user to choose (or keep) one of the two > > implementations? > good point! Thanks :) > I noticed that imagemagick contains mogrify-im6.q16, but missed > that it makes that available as mogrify via the alternatives system. Yeah, this looks a bit complicated with plain imagemagick, versioned imagemagick-something packages, and then graphicsmagick-imagemagick-compat which Conflicts/Replaces/Provides imagemagick. > Since graphicsmagick uses "gm" and ...-compat is "just" a compatiblity > package, I'm even considering using > "imagemagick | imagemagick-6.q16hdri | graphicsmagick-imagemagick-compat" > (different order plus ...hdri variant). Sounds good as well. (Personally I'd be a bit wary about packages with versions in their name but that's just my personal taste.) Thanks again, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1018264: fixed in kernel 6.0.0-4
It works with the kernel 6.0.0-4.
Bug#1024723: xavs2: do not release with bookworm
Source: xavs2 Version: 1.3-1 Severity: serious X-Debbugs-Cc: sramac...@debian.org The library is currently not used, so let's not release it with bookworm. Cheers -- Sebastian Ramacher
Bug#1024722: davs2: do not release with bookworm
Source: davs2 Version: 1.6-1 Severity: serious X-Debbugs-Cc: sramac...@debian.org The library is not used, so let's not include it in bookworm. Cheers -- Sebastian Ramacher
Bug#1024712: jhead: New dependency on graphicsmagick-imagemagick-compat
Hi Gregor, [...] > Now I'm wondering if changing the runtime dependency to "graphicsmagick-imagemagick-compat | imagemagick" would achieve the same while allowing the user to choose (or keep) one of the two implementations? good point! I noticed that imagemagick contains mogrify-im6.q16, but missed that it makes that available as mogrify via the alternatives system. Since graphicsmagick uses "gm" and ...-compat is "just" a compatiblity package, I'm even considering using "imagemagick | imagemagick-6.q16hdri | graphicsmagick-imagemagick-compat" (different order plus ...hdri variant). Best regards, Joachim
Bug#969202: ITA: binutils-avr -- Binary utilities supporting Atmel's AVR targets
Control: retitle -1 RFA: binutils-avr -- Binary utilities supporting Atmel's AVR targets Control: noowner -1 On Wed, 12 Oct 2022 11:32:41 -0700 Steve M wrote: Joshua, It has been a little over a year since you changed binutils-avr from RFA to ITA. Do you still intend to proceed with this adoption? If not, please consider returning it to RFA as I am considering adopting avr-libc, binutils-avr, and gcc-avr as a group. I would like to sponsor this. Please reach out when you have a package ready.
Bug#1024721: dh-lua: stop using libtool-bin
Source: dh-lua Version: 27+nmu1 Tags: patch X-Debbugs-Cc: debian-cr...@lists.debian.org Hi, I would like to delete the libtool-bin package. The next paragraph explains why. You may skip it if you don't care. libtool-bin used to be part of libtool. When we started cross building stuff, we wanted to mark libtool Multi-Arch foreign, but it contained /usr/bin/libtool which very much is architecture-dependent, so that was wrong. The way forward was to move /usr/bin/libtool out of libtool into a new package libtool-bin. Back then, we did an archive rebuild and lots of places actually didn't need /usr/bin/libtool. Another pile was converted to avoid needing libtool. The rest simply got a libtool-bin dependency. Now /usr/bin/libtool is not how libtool is meant to be used. In theory, you're supposed to libtoolize and create a libtool as part of the build. In particular, /usr/bin/libtool cannot be used for cross builds, but if you create a libtool during build, it will support cross builds. Thus we want to remove the libtool-bin package and /usr/bin/libtool from the archive. I've come up with a patch that creates a libtool when needed in debian/.dh_lua-libtool. With this patch applied, I can drop the libtool-bin dependency. I've done a test build of lua-geoip using this the patched dh-lua and see that it builds successfully without pulling the libtool-bin package. So I went ahead and used ratt to check for possible failures in those 103 reverse dependencies and found the following failures: - axtls is broken by my patch, because it injects -laxtls into compiler flags picked up by configure. - elektra #956949 - hamlib is broken by my patch, because it injects a non-existent object file into compiler flags picked up by configure. - libguestfs FTBFS on buildds - lua-apr #935271 - lua-cyrussasl is broken by my patch, because it injects shell code into compiler flags picked up by configure and configure passes that code to the compiler verbatim. - lua-zip is broken by my patch, because it injects shell code into compiler flags picked up by configure and configure passes that code to the compiler verbatim. - luasocket is broken by my patch, because of a quoting issue in the generated configure arising from LTCFGFLAGS containing quotes. - neomutt #1023767 - rrdtool is broken by my patch, because it injects -lrrd into compiler flags picked up by configure. So applying this patch would make six additional packages FTBFS. Of those, axtls and rrdtool try adding their library via CLIB_LDFLAGS. Both of them use a relative path with -L, which becomes invalid in configure. Adding $(CURDIR) may be a way to go here. hamlib could likewise prefix its object file with $(CURDIR). cyrus-sasl should use $(shell ...) instead of $$(...) to perform the shell evaluation. Likewise, lua-zip should use $(shell ...) in place of `...`. Finally, luasocket is difficult. Getting the quoting through the flags seems next to impossible, so I'd suggest moving the affected macros to a file and pass an -include flag via CFLAGS. Does this sound like we can move forward with this patch? I know it is not of the "it just works" kind. Helmut diff --minimal -Nru dh-lua-27+nmu1/Makefile dh-lua-27+nmu2/Makefile --- dh-lua-27+nmu1/Makefile 2020-06-30 18:22:21.0 +0200 +++ dh-lua-27+nmu2/Makefile 2022-11-23 16:21:50.0 +0100 @@ -31,6 +31,7 @@ cp test/5.2/* $(DESTDIR)/$(DH_LUA_HOME)/test/5.2/ cp test/5.3/* $(DESTDIR)/$(DH_LUA_HOME)/test/5.3/ cp test/5.4/* $(DESTDIR)/$(DH_LUA_HOME)/test/5.4/ + cp data/configure.ac $(DESTDIR)/$(DH_LUA_HOME)/ cp debhelper7/buildsystem/* $(DESTDIR)/$(DH_HOME)/Buildsystem/ cp debhelper7/sequence/* $(DESTDIR)/$(DH_HOME)/Sequence/ cat doc/policy.txt | sed 's/@@V@@/$(POLICY_VERSION)/' \ diff --minimal -Nru dh-lua-27+nmu1/data/configure.ac dh-lua-27+nmu2/data/configure.ac --- dh-lua-27+nmu1/data/configure.ac1970-01-01 01:00:00.0 +0100 +++ dh-lua-27+nmu2/data/configure.ac2022-11-23 16:21:50.0 +0100 @@ -0,0 +1,4 @@ +dnl this is a minimal configure.ac for creating a libtool +AC_INIT([dummy],[1.0]) +LT_INIT +AC_OUTPUT diff --minimal -Nru dh-lua-27+nmu1/debian/changelog dh-lua-27+nmu2/debian/changelog --- dh-lua-27+nmu1/debian/changelog 2022-09-03 11:25:48.0 +0200 +++ dh-lua-27+nmu2/debian/changelog 2022-11-23 16:21:50.0 +0100 @@ -1,3 +1,10 @@ +dh-lua (27+nmu2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Stop using libtool-bin. (Closes: #-1) + + -- Helmut Grohne Wed, 23 Nov 2022 16:21:50 +0100 + dh-lua (27+nmu1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru dh-lua-27+nmu1/debian/control dh-lua-27+nmu2/debian/control --- dh-lua-27+nmu1/debian/control 2020-06-30 18:22:21.0 +0200 +++ dh-lua-27+nmu2/debian/control 2022-11-23 16:21:50.0 +0100 @@ -11,7 +11,7 @@ Package: dh-lua Architecture: all -Depends:
Bug#1007694: beav: please consider upgrading to 3.0 source format
Please find the NMU debdiff attached.diff -Nru beav-1.40/beav.1 beav-1.40/beav.1 --- beav-1.40/beav.12022-11-23 20:59:11.0 +0100 +++ beav-1.40/beav.11970-01-01 01:00:00.0 +0100 @@ -1,63 +0,0 @@ -.TH BEAV 1 "" "" \" -*- nroff -*- -.SH NAME -beav \- binary file editor and viewer -.SH SYNOPSIS -.B beav -[file...] -.SH DESCRIPTION -This is a brief description of the minimal set of commands -that are necessary to start using -.IR beav -effectively. -For more information, review the file /usr/share/doc/beav/beav140.txt.gz. -.PP -The \fIfile-visit\fR command,\fB Ctl-X Ctl-V\fR, can be used to read a -file in for editing. The file can also be read in from the -command line; \fBbeav \fR. -.PP -Data is displayed in one or more windows. -These commands can be used to navigate around the windows. -.PP -.RS -\fImove-back-char\fB Ctl-B\fB moves left\fR -.br -\fImove-back-line\fB Ctl-P\fB moves up\fR -.br -\fImove-forw-char\fb Ctl-F\fB moves right\fR -.br -\fImove-forw-line\fB Ctl-N\fB moves down\fR -.br -\fIwindow-delete\fB Ctl-X 0\fB delete window\fR -.br -\fIwindow-expand\fB Ctl-X 1\fB expand window\fR -.br -.RE -.PP -The \fImove-to-byte\fR command,\fB Ctl-X G\fR, will prompt you for a -byte position to move to. -.PP -These commands will insert a zero byte at the cursor -position or delete the byte at that position. -.PP -.RS -\fIinsert-unit\fB Ctl-X I\fR -.br -\fIdelete-forw-unit\fBEsc D\fR -.br -.RE -.PP -The \fIfile-save\fR command,\fB Ctl-X Ctl-S\fR, will save the data to -the file if a change has been made. -.PP -The \fIhelp\fR command,\fB Esc ?\fR, will display a list of all -commands and their current key bindings. -.PP -The \fIabort-cmd\fR command,\fB Ctl-G\fR, will abort any command that -is in operation. -.PP -The \fIquit-no-save\fR command,\fB Ctl-X Ctl-C\fR, will exit beav. -If there is any data that has not been saved you will be warned. -.PP -.SH FILES -/usr/share/doc/beav/beav140.txt.gz - diff -Nru beav-1.40/buffer.c beav-1.40/buffer.c --- beav-1.40/buffer.c 2022-11-23 20:59:11.0 +0100 +++ beav-1.40/buffer.c 1994-11-30 18:43:35.0 +0100 @@ -2,8 +2,6 @@ * Buffer handling. */ -#include -#include #include"def.h" bool onebuf (); @@ -168,7 +166,7 @@ if ((s = ereply (MSG_kill_b, bufn, NBUFN, 0)) != TRUE) return (s); -if ((s = _killbuffer (bufn))) +if (s = _killbuffer (bufn)) writ_echo (okmsg); /* verbose-ness (jam) */ return (s); } @@ -807,7 +805,7 @@ register LINE *lp; char name[NBUFN + 1]; char buf[3]; -//WINDOW *wp; +WINDOW *wp; lp = curwp->w_dotp;/* get the buffer name from the line */ diff -Nru beav-1.40/debian/changelog beav-1.40/debian/changelog --- beav-1.40/debian/changelog 2022-11-23 20:59:11.0 +0100 +++ beav-1.40/debian/changelog 2022-11-23 20:55:42.0 +0100 @@ -1,3 +1,10 @@ +beav (1:1.40-18.4) unstable; urgency=medium + + * Non-maintainer upload. + * Convert to 3.0 source format (Closes: #1007694). + + -- Bastian Germann Wed, 23 Nov 2022 20:55:42 +0100 + beav (1:1.40-18.3) unstable; urgency=medium * Non-maintainer upload. diff -Nru beav-1.40/debian/patches/debian.patch beav-1.40/debian/patches/debian.patch --- beav-1.40/debian/patches/debian.patch 1970-01-01 01:00:00.0 +0100 +++ beav-1.40/debian/patches/debian.patch 2022-11-23 20:55:42.0 +0100 @@ -0,0 +1,1336 @@ +--- /dev/null beav-1.40/Makefile +@@ -0,0 +1,25 @@ ++# This is the makefile for BSD UNIX ++#CFLAGS= -g -DUNIX ++CFLAGS= -g -DUNIX -Wall ++CC=gcc ++ ++OFILES= basic.o ebcdic.o fileio.o region.o text.o wangpc.o \ ++ buffer.o echo.o language.o main.o search.o tty.o window.o \ ++ cinfo.o extend.o kbd.o spawn.o ttyio.o termio.o tcap.o word.o \ ++ display.o file.o line.o random.o symbol.o ttykbd.o format.o ++ ++ ++CFILES= basic.c ebcdic.c fileio.c region.c text.c wangpc.c \ ++ buffer.c echo.c language.c main.c search.c tty.c window.c \ ++ cinfo.c extend.c kbd.c spawn.c ttyio.c termio.c tcap.c word.c \ ++ display.c file.c line.c random.c symbol.c ttykbd.c ++ ++HFILES= def.h prototyp.h ++ ++beav: $(OFILES) ++ $(CC) $(CFLAGS) $(OFILES) -lncurses -o beav ++ ++clean: ++ rm -f *.o beav ++ ++(OFILES): $(HFILES) +--- /dev/null beav-1.40/beav.1 +@@ -0,0 +1,63 @@ ++.TH BEAV 1 "" "" \" -*- nroff -*- ++.SH NAME ++beav \- binary file editor and viewer ++.SH SYNOPSIS ++.B beav ++[file...] ++.SH DESCRIPTION ++This is a brief description of the minimal set of commands ++that are necessary to start using ++.IR beav ++effectively. ++For more information, review the file /usr/share/doc/beav/beav140.txt.gz. ++.PP ++The \fIfile-visit\fR command,\fB Ctl-X Ctl-V\fR, can be used to read a ++file in for editing. The file can also be read in from the ++command line; \fBbeav \fR. ++.PP ++Data is displayed in
Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
Hi Stuart, Thanks for the report! On Wed, Nov 23, 2022 at 06:31:48PM +, Stuart Hayhurst wrote: > Source: linux > Version: 5.19.6-1 > Severity: important > Tags: patch upstream > X-Debbugs-Cc: stuart.a.hayhu...@gmail.com > > Dear Maintainer, > > The Samsung PM9B1 misreports its NID when resuming from sleep, > causing the root filesystem to be unmounted, and the system left in > an unstable state. Mostly this results in the device crashing, but > if the device somehow continues running, it's incredibly unstable, > where basically nothing works. It's an OEM drive found in some newer > laptops (like my Lenovo Yoga 7 Gen 7) > There's a bug report and patch upstream for this, but personally I > think it might be a good idea to include it in Debian until it's > accepted, as machines with this drive are near-unusable. > Upstream issue: > https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ > I've tested the patch against the current Debian 6.1-rc5 kernel on > my laptop, and this fixes the problem without any other issues. On the other hand, we only should include it once we are fairly confident that upstream accepts the fix and will include. Can you ping this bug once upstream maintainers have acked the change and queued it? If you have tested the patch, then you can as well reply to the thread mentioning you sucessfully tested the patch adding a Tested-by tag. Regards, Salvatore
Bug#1024322: transition: dpdk
Control: tags -1 moreinfo On 2022-11-17 14:27:25 +, Luca Boccassi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org > > Hello Thomas and Release Team, > > As we did for Bullseye, we are proposing the following plan to allow > Bookworm to ship with the latest LTS versions of DPDK and OVS. This > will let us make use of the full LTS support windows for both projects, > as we have done for the past few releases. > > Upload OVS built from git (with new sonames/package renames if > necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable, > ideally before the 16th as we go on vacation after that, to finish the > transition. > > Then, after OVS 3.1 releases in February, upload it unstable (no > soname/transition required, as only bug fixes will go in at that > point). The upstream release might happen before or after the > 2023/02/12 soft freeze, and if it is after we will ask for an > exception. > > Would this plan work for everyone? Sounds like that should work like last time. Please remove the moreinfo tag once dpdk is ready for the upload to unstable. Cheers > > Bullseye tickets for reference: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974588 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974667 > > -- > Kind regards, > Luca Boccassi -- Sebastian Ramacher
Bug#1024047: python-line-profiler FTBFS with Python 3.11 as supported version
Control: tag -1 + fixed-upstream Upstream claims that version 4.0.0 supports Python 3.11. I tried backporting a minimal patch to bring 3.11 support back, but tests fail. So... time to stop kicking this can down the road and update to the latest upstream version. SR
Bug#1024720: d-i fails at grub when another installer is on disk
Package: installation-reports Severity: normal Boot method: USB Image version: firmware-testing-amd64-netinst.iso (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-cd/; 2022-11-21) Date: Wed, 23 Nov 2022 20:27:28 +0100 Machine: Lenovo Thinkpad X13 Yoga Gen3 This machine came with an Ubuntu Installer on disk, in nvme0n1p2. This confused the grub on the installer image as it did not find the correct root partition: } grub> search --file --set=root /.disk/info } grub> echo $root } hd0,gpt2 As opposed to (cd0). A workaround was to rename the .disk/info file on nvme0n1p2. A fix might be if each installer image used and searched for a unique file. Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#915444: ITP: aspell-el -- Greek dictionary for GNU Aspell
Control: retitle -1 O: aspell-el -- Greek dictionary for GNU Aspell Control: noowner -1 The adoption did not happen.
Bug#1024707: [pkg-apparmor] Bug#1024707: aa-disable fails if HOMEDIRS is used as tunable
Hello,
Am Mittwoch, 23. November 2022, 15:58:30 CET schrieb Erik Thiele:
> Package: apparmor-utils
> Version: 2.13.2-10
> # cat /etc/apparmor.d/tunables/home.d/yyy
> @{HOMEDIRS}+=/home/global/
> # aa-disable usr.bin.thunderbird
> ERROR: Values added to a non-existing variable
> @{HOMEDIRS}: /home/global/ in tunables/home.d/yyy
> this may be linked to
> https://bugs.launchpad.net/apparmor/+bug/1331856
Indeed, and the relevant part is comment 16:
This bug is finally fixed with
https://gitlab.com/apparmor/apparmor/-/merge_requests/544
AppArmor 3.0 will include the fixed tools.
Unfortunately you / your Debian version still have 2.13.x, and the merge
request is too big to backport it to the 2.13 branch.
As long as you stay with AppArmor 2.13.x and want to use the aa-* tools,
the workaround is to edit /etc/apparmor.d/tunables/home instead of
using a home.d/ file to extend a variable with +=
Regards,
Christian Boltz
--
> I like science when some "vodoo" is needed to make it work ;-)
Magic is just another word for indistinguishable advanced technology :D
[> Bruno Friedmann and Jan Engelhardt in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#1024719: linphone-desktop: New version 5.0 available upstream
Package: linphone-desktop Version: 4.2.5-3 Severity: normal Worth jumping forward to this release.. I've tested the new one as an apt package - seems to work well - other than bug 983365. This is version 5.0.0-beta At5.12.12 https://github.com/BelledonneCommunications/linphone-desktop/tree/release/5.0 -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64)
Bug#1023846: transition: gdal
On 11/23/22 19:22, Paul Gevers wrote:
On 23-11-2022 05:28, Sebastiaan Couwenberg wrote:
The libgdal-grass autopkgtest in testing is failing because it
requires gdal, grass, and libgdal-grass from unstable.
https://qa.debian.org/excuses.php?package=gdal
This combination needs to be tested to fix the regressions shown and
unblock testing migration of gdal and the related rebuilt packages.
I'll schedule the set, but I have the feeling that a proper versioned
relation (maybe an upper limit??) is missing somewhere. As there are
quite a few versioned binaries involved already, it's obvious that
there's a design. But if there's a runtime check for a version, ideally
that should be expressed in dependencies too. Unless I'm missing
something of course. (If that dependency would be there, britney would
ask apt to pin packages from the source providing it from unstable if
they are not fulfilled in testing).
"""
ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying
to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
"""
This is not reflected in the dependencies, only the ABI dependency
provided by grass-core is set:
grass820
The dependency is set with a dh_gencontrol override.
This version check in grass is much stricter than it should be, the
builds from the upstream git repo use the commit hash of include
directory to check whether the code using grass is still compatible.
Because this requirement to rebuild libgdal-grass everytime grass is
rebuilt annoyed me, I dug into this issue and had it changed upstream to
use the full GRASS version (e.g. 8.2.0) like the virtual ABI dependency
provided by grass-core for tarball builds.
GRASS 8.2.1 will contain this change, with their release process slower
than expected, it's not sure whether it will be released before the
bookworm freeze.
For future gdal transitions pulling in only the new gdal from unstable
may suffice, although grass from testing still using the old gdal may
cause different problems than just this version check. Like the crssync
segfaults tend that happen with qgis when its dependencies are linked to
different libproj versions.
"""
ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current
library version is 3.6
ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the
current library version is 3.6
"""
This is reflected in the libgdal-grass (1:1.0.2-2) dependencies:
libgdal32 (>= 3.6.0)
Those are the normal ${shlibs:Depends} set via symbols files.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
Source: linux Version: 5.19.6-1 Severity: important Tags: patch upstream X-Debbugs-Cc: stuart.a.hayhu...@gmail.com Dear Maintainer, The Samsung PM9B1 misreports its NID when resuming from sleep, causing the root filesystem to be unmounted, and the system left in an unstable state. Mostly this results in the device crashing, but if the device somehow continues running, it's incredibly unstable, where basically nothing works. It's an OEM drive found in some newer laptops (like my Lenovo Yoga 7 Gen 7) There's a bug report and patch upstream for this, but personally I think it might be a good idea to include it in Debian until it's accepted, as machines with this drive are near-unusable. Upstream issue: https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ I've tested the patch against the current Debian 6.1-rc5 kernel on my laptop, and this fixes the problem without any other issues. Thanks :) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1019296: Processed (with 1 error): Re: tt-rss - build-dependencies unsatisfiable
Control: forcemerge -1 1020066 On woensdag 23 november 2022 18:39:05 CET you wrote: > > merge -1 1020066 > > Bug #1019296 [src:tt-rss] tt-rss - build-dependencies unsatisfiable > Unable to merge bugs because: signature.asc Description: This is a digitally signed message part.
Bug#1023846: transition: gdal
Hi Bas, On 23-11-2022 05:28, Sebastiaan Couwenberg wrote: The libgdal-grass autopkgtest in testing is failing because it requires gdal, grass, and libgdal-grass from unstable. https://qa.debian.org/excuses.php?package=gdal This combination needs to be tested to fix the regressions shown and unblock testing migration of gdal and the related rebuilt packages. I'll schedule the set, but I have the feeling that a proper versioned relation (maybe an upper limit??) is missing somewhere. As there are quite a few versioned binaries involved already, it's obvious that there's a design. But if there's a runtime check for a version, ideally that should be expressed in dependencies too. Unless I'm missing something of course. (If that dependency would be there, britney would ask apt to pin packages from the source providing it from unstable if they are not fulfilled in testing). """ ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS or untangle multiple installations. """ """ ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current library version is 3.6 ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the current library version is 3.6 """ Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1024717: aewm++: NMU 1.1.2-5.3
Source: aewm++
Version: 1.1.2-5.3
The debdiff for the LowNMU is attached.diff -Nru aewm++-1.1.2/aewm.hh aewm++-1.1.2/aewm.hh
--- aewm++-1.1.2/aewm.hh2022-11-23 19:08:06.0 +0100
+++ aewm++-1.1.2/aewm.hh2005-02-20 03:05:27.0 +0100
@@ -47,7 +47,7 @@
#define FOCUSED_WINDOW_TITLE_COLOR "#FF"
-#define DEF_NEW1 "x-terminal-emulator -ls -sb -bg black -fg white"
+#define DEF_NEW1 "xterm -ls -sb -bg black -fg white"
#define DEF_BW 1
#define SPACE 3
#define MINSIZE15
diff -Nru aewm++-1.1.2/client.cc aewm++-1.1.2/client.cc
--- aewm++-1.1.2/client.cc 2022-11-23 19:08:06.0 +0100
+++ aewm++-1.1.2/client.cc 2005-02-20 03:07:22.0 +0100
@@ -6,8 +6,6 @@
*/
#include "aewm.hh"
-#include
-
Client::Client(Display *d, Window new_client)
{
initialize(d);
diff -Nru aewm++-1.1.2/debian/changelog aewm++-1.1.2/debian/changelog
--- aewm++-1.1.2/debian/changelog 2022-11-23 19:08:06.0 +0100
+++ aewm++-1.1.2/debian/changelog 2022-11-23 18:27:25.0 +0100
@@ -1,3 +1,10 @@
+aewm++ (1.1.2-5.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Convert to source format 3.0.
+
+ -- Bastian Germann Wed, 23 Nov 2022 18:27:25 +0100
+
aewm++ (1.1.2-5.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru aewm++-1.1.2/debian/patches/debian.patches
aewm++-1.1.2/debian/patches/debian.patches
--- aewm++-1.1.2/debian/patches/debian.patches 1970-01-01 01:00:00.0
+0100
+++ aewm++-1.1.2/debian/patches/debian.patches 2022-11-23 18:27:25.0
+0100
@@ -0,0 +1,25 @@
+Description: Debian patches
+---
+--- aewm++-1.1.2.orig/Makefile
aewm++-1.1.2/Makefile
+@@ -35,8 +35,7 @@ $(OBJS): %.o: %.cc $(HEADERS)
+
+ install: all
+ mkdir -p $(DESTDIR)$(prefix)/bin
+- mkdir -p $(DESTDIR)$(prefix)/man/man1
+- install -s aewm++ $(DESTDIR)$(prefix)/bin
++ install aewm++ $(DESTDIR)$(prefix)/bin
+
+ clean:
+ rm -f aewm++ $(OBJS) core
+--- aewm++-1.1.2.orig/windowmanager.cc
aewm++-1.1.2/windowmanager.cc
+@@ -540,7 +542,7 @@ void WindowManager::handleKeyPressEvent(
+ {
+ if( (unsigned)current_desktop != ks - XK_1 )
+ {
+- (unsigned)current_desktop = ks - XK_1;
++ current_desktop = ks - XK_1;
+ goToDesktop(current_desktop);
+ }
+ }
diff -Nru aewm++-1.1.2/debian/patches/missing-string.patch
aewm++-1.1.2/debian/patches/missing-string.patch
--- aewm++-1.1.2/debian/patches/missing-string.patch1970-01-01
01:00:00.0 +0100
+++ aewm++-1.1.2/debian/patches/missing-string.patch2022-11-23
18:27:25.0 +0100
@@ -0,0 +1,35 @@
+Description: Add missing string.h
+---
+--- aewm++-1.1.2.orig/client.cc
aewm++-1.1.2/client.cc
+@@ -6,6 +6,8 @@
+ */
+ #include "aewm.hh"
+
++#include
++
+ Client::Client(Display *d, Window new_client)
+ {
+ initialize(d);
+--- aewm++-1.1.2.orig/main.cc
aewm++-1.1.2/main.cc
+@@ -6,6 +6,8 @@
+ */
+ #include "aewm.hh"
+
++#include
++
+ // Dunno where I ripped this from. Kudos to the author whoever he is!
+ void forkExec(char *cmd)
+ {
+--- aewm++-1.1.2.orig/windowmanager.cc
aewm++-1.1.2/windowmanager.cc
+@@ -6,6 +6,8 @@
+ */
+ #include "aewm.hh"
+
++#include
++
+ WindowManager* wm;
+
+ #define AEWM_KEY_ALT_COUNT 4
diff -Nru aewm++-1.1.2/debian/patches/series aewm++-1.1.2/debian/patches/series
--- aewm++-1.1.2/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ aewm++-1.1.2/debian/patches/series 2022-11-23 18:27:25.0 +0100
@@ -0,0 +1,4 @@
+debian.patches
+missing-string.patch
+x11-paths.patch
+x-terminal-emulator.patch
diff -Nru aewm++-1.1.2/debian/patches/x11-paths.patch
aewm++-1.1.2/debian/patches/x11-paths.patch
--- aewm++-1.1.2/debian/patches/x11-paths.patch 1970-01-01 01:00:00.0
+0100
+++ aewm++-1.1.2/debian/patches/x11-paths.patch 2022-11-23 18:27:25.0
+0100
@@ -0,0 +1,15 @@
+Description: Don't use obsolete X11R6 paths to build
+---
+--- aewm++-1.1.2.orig/Makefile
aewm++-1.1.2/Makefile
+@@ -2,8 +2,8 @@ CC = g++
+ ADDITIONAL_CFLAGS = -g -O2 -march=i686 -Wall
+
+ prefix = /usr
+-INCLUDES = -I$/usr/X11R6
+-LDPATH = -L/usr/X11R6/lib
++INCLUDES = -I/usr/include/X11
++LDPATH = -L/usr/lib/X11
+ LIBS = -lXext -lX11
+
+ # SHAPE = Shape Extension
diff -Nru aewm++-1.1.2/debian/patches/x-terminal-emulator.patch
aewm++-1.1.2/debian/patches/x-terminal-emulator.patch
--- aewm++-1.1.2/debian/patches/x-terminal-emulator.patch 1970-01-01
01:00:00.0 +0100
+++ aewm++-1.1.2/debian/patches/x-terminal-emulator.patch 2022-11-23
18:27:25.0 +0100
@@ -0,0 +1,14 @@
+Description: Changed references to xterm to x-terminal-emulator
+ to use the user's preferred version according to /etc/alternatives
+---
+--- aewm++-1.1.2.orig/aewm.hh
aewm++-1.1.2/aewm.hh
+@@ -47,7 +47,7 @@ using
Bug#924685: RFP: cumin -- An automation and orchestration framework
Hi, > Heck, you shouldn't even need to build your own debs if we do this > right; this will trickle down to bookworm and, from there, backports, > ubuntu, etc. Agreed, from my perspective an upstream-included debian/ dir is only useful until it gets packaged. From that point onwards fetching a Debian source package for rebuilds is way simpler and downstream distros like Ubuntu sync from Debian anyway instead of an upstream repo. It's also one thing less to maintain/keep in sync. Cheers, Moritz
Bug#1024657: nvidia-libopencl1: Inconsistency between changelog and package description regarding supported OpenCL versions
Control: tag -1 pending On 22/11/2022 19.48, Ben Morris wrote: The package description states "This library supports OpenCL 1.x and 2.0 only". However, the changelog says "nvidia-libopencl1 now supports up to OpenCL 3.0." as of 460.27.04-1. Good catch! Andreas
Bug#1023476: runit: Improve default-syslog check
On Wed, Nov 16, 2022 at 02:03:14PM +0100, Lorenzo wrote: > > > lsof /dev/log >/dev/null || exit 1 > > > > I think > > > > fuser /dev/log >/dev/null 2>/dev/null || exit 1 > > > > is more efficient, but there is a problem with both approaches: the process > > that is listening on /dev/null may be invisible to us, because it may be > > running in a different namespace. > > Thanks for the above: I didn't thought about using this service inside a > container (when the logger is outside) and I agree it's a nice to have > extension (assuming that you mean listening on /dev/log, otherwise I fail to > understand what you are talking about) Yes, sorry, my brain hit a bad sector there. /dev/log of course. > > The only way to reliably determine whether there is a Unix server listening > > on the /dev/log socket is to try to connect to the socket. > > > > One approach I can think of is to use > > > > unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type > > for socket' || exit 1 > > > > This creates a SOCK_STREAM socket and tries to connect it to /dev/log, > > which will fail with EPROTOTYPE if there is a listening server (which will > > use SOCK_DGRAM) and with ECONNREFUSED if not. > > > > Using unixclient would introduce a semi-esoteric dependency on ucspi-unix, > > but it's a tiny package which is a good match for the runit ecosystem > > anyway, so maybe it's acceptable. > > > > A more mainstream but much more heavyweight approach would be to use > > socat(1) or netcat-openbsd with the -U option. > > > > Alternatively, socklog provides its own socklog-check, which does exactly > > what is necessary, but the whole point of trying to detect whether *any* > > syslog daemon is running is to avoid having to install a particular one > > like socklog, so we probably shouldn't use it. > > > > OTOH, it's such a tiny program, and so unlikely to require changes ever, > > you might even ship (a copy of) it as part of the runit package. > > I'm ok with ucspi-unix or socklog-check, but this can happen only after the > bookworm release. How about you make default-syslog/check use socklog-check or unixclient if they are available, and fall back to the current heuristics if not? Something like this: #!/bin/sh # note: only socklog exists as runit service in Debian right now socklog-check && exit 0 unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type for socket' && exit 0 fuser /dev/log >/dev/null 2>/dev/null && exit 0 for service in rsyslog socklog socklog-unix syslog-ng busybox-syslogd inetutils-syslogd ; do sv u $service && sv check $service && exit 0 done exit 1 If socklog-check and unixclient aren't installed, those commands will just fail and the script will fall back to the next attempt. The only way I can see this being worse than the current solution is if searching PATH for executables is pathologically slow (e.g. due to an NFS outage maybe). > This bug can probably renamed as "default-syslog: useless inside a > container", right ? I don't think so; that wouldn't be accurate. It's only useless if the syslog daemon and the check script run in different namespaces; if they run in the same container, it works, and it also fails if check runs on the host and it's the syslog daemon that's in the container (this should be rare though). I'd call it "default-syslog: check for running syslogd not robust" or something. András -- Desk: A very large wastebasket with drawers.
Bug#1019296: tt-rss - build-dependencies unsatisfiable
Control: reassign -1 src:tt-rss 21~git20210204.b4cbc79+dfsg-1 Control: tag -1 = bookworm ftbfs pending sid Control: severity -1 serious Control: merge -1 1020066 On 7 Sep 2022 01:15:32 +0100 Peter Michael Green wrote: > Package: tt-rss > Version: 21~git20210204.b4cbc79+dfsg-1 > Serverity: serious > Tags: bookworm, sid > > tt-rss build-depends on libjs-prototype (= 1.7.1-3.1) but > testing/unstable has version 1.7.3-1 This is the same bug as #1020066, so merging with that, which should close it with version tt-rss/21~git20210204.b4cbc79+dfsg-1.2 signature.asc Description: This is a digitally signed message part.
Bug#1008972: firmware-iwlwifi: iwlwifi reports errors while shutdown computer
Now I tried out the version from bullseye-backports, this did not improve anything significant. I can't try the unstable version here. On Sat, 29 Oct 2022 01:20:55 +0200 Diederik de Haas wrote: > Control: tag -1 moreinfo > > On Tuesday, 5 April 2022 13:11:14 CEST dasebastian wrote: > > Package: firmware-iwlwifi > > Version: 20210315-3 > > > > after updating my system to bullseye, I mostly always get a lot of > > errors when shuting down the computer (if I was logged in into a > > wireless network). Things like: > > > > [ 536.451518] iwlwifi :03:00.0: Error sending > > REPLY_SCAN_ABORT_CMD: time out after 2000ms. [ 536.451668] iwlwifi > > :03:00.0: Current CMD queue read_ptr 28 write_ptr 29 [ > > 536.699549] iwlwifi :03:00.0: Loaded firmware version: > > 18.168.6.1 6000g2a-6.ucode > > > > -- System Information: > > Debian Release: 11.3 > > APT prefers stable-updates > > APT policy: (500, 'stable-updates'), (500, 'stable-security'), > > (500, 'stable') Architecture: amd64 (x86_64) > > Stable backports has version 20210818-1~bpo11+1, could you try and > report back whether that improves/fixes your issue? > > Unstable recently got version 20220913-1 and if the above version > didn't fix it, it would be useful to know whether the latest version > does.
Bug#1008972: (no subject)
Now I tried out the version from bullseye-backports, this did not improve anything significant. I can't try the unstable version here.
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2022-11-23 17:59:41, Riccardo Coccioli wrote: > On Wed, Nov 23, 2022 at 5:15 PM Moritz Mühlenhoff > wrote: > >> Hi Antoine, >> >> [Adding Riccardo Coccioli, my colleague at Wikimedia and the primary >> author of Cumin to CC] >> >> > which makes me wonder: should we drop the debian branch on github and >> > gerrit? or should we (say, debian sponsors) pull changes from you and >> > sync them to salsa? >> > >> > how should we play this long term? >> >> My proposal would be to discard the debian branch on gerrit/github and >> make salsa.debian.org the authoritative repository for Cumin debs (and >> just build backports for apt.wikimedia.org based on the latest version >> on salsa/unstable). >> >> But let's hear from Riccardo on this as well. >> >> Cheers, >> Moritz >> > > I'd like to better understand why it would be better/easier to move the > debian branch into salsa instead of leaving it attached to the upstream > project. I'm not that familiar with the whole debian process, so correct me > if I'm missing something obvious. Sure. It really depends on how you want to manage this package. So far I've been assuming I'd be doing some of the work at least, which means I'd need access to the git repo, hence salsa, where I can also grant *you* access. I suspect the reverse is not possible, and I wouldn't be able to contribute back to the wikimedia repositories myself... > It would seem to me that leaving the debian branch into the upstream > repository would also allow other distro/users to build their own deb > package using the same config without importing a separate repository. I don't think you need write access to the repository to build your own deb, that's the thing. If you just add a pointer in the wikimedia repo to salsa, people will know where to find the repo. Heck, you shouldn't even need to build your own debs if we do this right; this will trickle down to bookworm and, from there, backports, ubuntu, etc. > As for the debian/watch file if you don't mind I would like to upload a > slightly different one that I use for another project as the tags are all > signed and it does work with the new GitHub APIs (see also the recent "Q: > uscan with GitHub" thread in debian-devel). Oh, yes of course, I'd be happy to see that. Let me know if you want access to the salsa repo. I'm fine either way. a. -- For every complex problem, there is an answer that is clear, simple - and wrong. - H.L. Mencken
Bug#1024576: librepo: FTBFS against libgpgme-dev >= 1.18.0-2
Control: tags -1 patch
On 2022-11-21 Andreas Metzler wrote:
> Source: librepo
> Version: 1.12.1-4
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> User: pkg-gnupg-ma...@lists.alioth.debian.org
> Usertags: gpgme-config-transition^
> The package relies on gpgme-config to detect gpgme. gpgme-config has been
> dropped and replaced by pkg-config pc files.
Straightforward patch attached.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- librepo-1.12.1.orig/CMakeLists.txt
+++ librepo-1.12.1/CMakeLists.txt
@@ -30,8 +30,8 @@ FIND_PACKAGE(PkgConfig)
PKG_CHECK_MODULES(GLIB2 glib-2.0 REQUIRED)
PKG_SEARCH_MODULE(LIBCRYPTO REQUIRED libcrypto openssl)
PKG_CHECK_MODULES(LIBXML2 libxml-2.0 REQUIRED)
+PKG_SEARCH_MODULE(GPGME REQUIRED gpgme)
FIND_PACKAGE(CURL REQUIRED)
-FIND_PACKAGE(Gpgme REQUIRED)
IF (WITH_ZCHUNK)
--- librepo-1.12.1.orig/librepo/CMakeLists.txt
+++ librepo-1.12.1/librepo/CMakeLists.txt
@@ -50,7 +50,7 @@ TARGET_LINK_LIBRARIES(librepo
${LIBXML2_LIBRARIES}
${CURL_LIBRARY}
${LIBCRYPTO_LIBRARIES}
-${GPGME_VANILLA_LIBRARIES}
+${GPGME_LIBRARIES}
${GLIB2_LIBRARIES}
)
IF (WITH_ZCHUNK)
Bug#924685: RFP: cumin -- An automation and orchestration framework
On Wed, Nov 23, 2022 at 5:15 PM Moritz Mühlenhoff wrote: > Hi Antoine, > > [Adding Riccardo Coccioli, my colleague at Wikimedia and the primary > author of Cumin to CC] > > > which makes me wonder: should we drop the debian branch on github and > > gerrit? or should we (say, debian sponsors) pull changes from you and > > sync them to salsa? > > > > how should we play this long term? > > My proposal would be to discard the debian branch on gerrit/github and > make salsa.debian.org the authoritative repository for Cumin debs (and > just build backports for apt.wikimedia.org based on the latest version > on salsa/unstable). > > But let's hear from Riccardo on this as well. > > Cheers, > Moritz > I'd like to better understand why it would be better/easier to move the debian branch into salsa instead of leaving it attached to the upstream project. I'm not that familiar with the whole debian process, so correct me if I'm missing something obvious. It would seem to me that leaving the debian branch into the upstream repository would also allow other distro/users to build their own deb package using the same config without importing a separate repository. As for the debian/watch file if you don't mind I would like to upload a slightly different one that I use for another project as the tags are all signed and it does work with the new GitHub APIs (see also the recent "Q: uscan with GitHub" thread in debian-devel). Thanks both for resuming the work on this! Riccardo
