Bug#1083119: ITP: papilo -- Parallel Presolve for Integer and Linear Optimization
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: papilo Version : 2.3.0 Upstream Author : Zuse Institute Berlin (ZIB) * URL : https://github.com/scipopt/papilo * License : LGPL-3+, BSL-1, Zlib, Apache-2, BSD-3-clause, Expat Programming Lang: Python, C, C++ Description : Parallel Presolve for Integer and Linear Optimization PaPILO, a C++14-based software package, provides parallel presolve routines for (mixed integer) linear programming problems. The routines are implemented using templates which allows switching to higher precision or rational arithmetic using the boost multiprecision package. The package will be team-maintained under the umbrella of the Debian Math Team at https://salsa.debian.org/math-team/papilo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmb8fO4ACgkQzIxr3RQD 9Mr0Wg/+KBhlTlB4Kqp94bz2rbpU9C3ealKPLz0ER2SB9dVGDdTjEhwd6HzvXHlp a5xp/QkhrbwmtBbf7nA1fVcuAlvNLraRbhO9wqCdFtppB3U1WFDKVmJxrMbw3DFo q0JNyS3bUAVdC3u++23u90Pkyt8SatuvJhzwsT9bsGxtvlbNuRqVlyNAYyPKvJ7A N6dXj/DC4bUkMGXaKEOKbhinUDpmoQPO6byVMQBDqLTL5HePHnld9iwLINrEAXf5 8ZfFLqgwMuQCIlXEFly1CLI7yBCHb6pXdRKA91ckAJlYuvB34aonxYt8xIZ/+T2J sB6SMnUp0wNbNzl9ieFRmS5rILEt6MLNxlKLWuYGA4vjtQGn62VC8c4oLGn0EpvN Nhi+Jb6N62fanphrZKLswZNrXm1amVzeKxj2icmYlvXTwFN4StNRWv4hnV/1ngKK Cr2SI1oeRJmRQbbljkarJUhBDenpUlP8tTxxuva7o5TW54QWvOpDq9TZ7rX8SU+W ql2pciVvjC4tf/d59NJ4PYRShqGxLSefWfw6OBxbSAQGwtu1LvauBU/DBR53aVQZ UbyrSRj32B7sBQiuK6rjyAt6swojQGxEXtKg3U17LybnPzN9fgKSqpUIKZrWq0VW V6JAvD5hBSiPuSu5Q7GdD9xwgKqzIfD3vHGtPoIeaBU2Ew755TA= =XIGK -END PGP SIGNATURE-
Re: dpkg-maintscript-helper and usrmerge
Am 30.09.24 um 18:53 schrieb Mark Pearson: The firmware-sof-signed 2024.06 package: https://packages.debian.org/trixie/firmware-sof-signed In particular the sof-ipc4-tplg package that is being converted from a directory to a symlink. The dpkg-maintscript-helper complains about /usr/lib/firmware/intel/sof-ace-tplg (and it's contents) not being owned by the package - because they were all previously under /lib. I suspect this is more of a special case, so would like to see a few more details. Holler if you need anything else. I test upgraded firmware-sof-signed from bookworm to trixie. The bookworm chroot was usrmerged. # ls -ld /lib lrwxrwxrwx 1 root root 7 Oct 1 10:07 /lib -> usr/lib ... Preparing to unpack .../firmware-sof-signed_2024.06-1_all.deb ... Unpacking firmware-sof-signed (2024.06-1) over (2.2.4-1) ... dpkg: warning: unable to delete old directory '/lib/firmware/intel/sof-tplg': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/intel/sof/intel-signed': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/intel/sof/community': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/intel/sof': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/intel': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware': Directory not empty Setting up firmware-sof-signed (2024.06-1) ... ... # ls /usr/lib/firmware/intel/ -la total 72 drwxr-xr-x 6 root root 4096 Oct 1 10:09 . drwxr-xr-x 3 root root 4096 Oct 1 10:08 .. drwxr-xr-x 4 root root 4096 Oct 1 10:09 sof lrwxrwxrwx 1 root root13 Sep 9 18:55 sof-ace-tplg -> sof-ipc4-tplg drwxr-xr-x 14 root root 4096 Oct 1 10:09 sof-ipc4 drwxr-xr-x 2 root root 4096 Oct 1 10:09 sof-ipc4-tplg drwxr-xr-x 2 root root 53248 Oct 1 10:09 sof-tplg The above looks all expected. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1083083: ITP: esphome -- system to create firmwares for ESP32/ESP8266 super easy
Package: wnpp Severity: wishlist Owner: Piotr Ożarowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: esphome Version : 2024.9.2 Upstream Contact: ESPHome * URL : https://esphome.io * License : MIT Programming Lang: C, C++, Python Description : system to create firmwares for ESP32/ESP8266 super easy ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems
Bug#1083079: ITP: libqt6pas -- Qt6 interface bindings for Pascal
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com, pkg-pascal-de...@alioth-lists.debian.net * Package name : libqt6pas Version : 1 Upstream Contact: N/A (See URL below) * URL : https://www.lazarus-ide.org/index.php * License : GPL2+ Programming Lang: C++, Pascal Description : Qt6 interface bindings for Pascal Provides interface for Pascal applications to the Qt6 C++ libraries. This binding does not cover the whole Qt6 framework, it just contains all classes needed to use Qt6 as a widgetset. This will enable Lazarus packages to built for Qt6. (Similar functionality is provided by libqtpas for Qt5) Package to be maintained by Debian Pascal Maintainers Regards, Peter
Re: dpkg-maintscript-helper and usrmerge
Am 01.10.24 um 12:17 schrieb Michael Biebl: Am 30.09.24 um 18:53 schrieb Mark Pearson: The firmware-sof-signed 2024.06 package: https://packages.debian.org/trixie/firmware-sof-signed In particular the sof-ipc4-tplg package that is being converted from a directory to a symlink. The dpkg-maintscript-helper complains about /usr/lib/firmware/intel/ sof-ace-tplg (and it's contents) not being owned by the package - because they were all previously under /lib. I suspect this is more of a special case, so would like to see a few more details. Holler if you need anything else. I test upgraded firmware-sof-signed from bookworm to trixie. The bookworm chroot was usrmerged. Ok, I see the problem now. The issue is, that the path used in dir_to_symlink changed pre and post usrmove. I don't think you can express that via a .maintscript file. The attached debdiff should do. Regards, Michael diff -Nru firmware-sof-2024.06/debian/changelog firmware-sof-2024.06/debian/changelog --- firmware-sof-2024.06/debian/changelog 2024-09-09 20:55:13.0 +0200 +++ firmware-sof-2024.06/debian/changelog 2024-10-01 13:18:36.0 +0200 @@ -1,3 +1,11 @@ +firmware-sof (2024.06-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use correct path for dir_to_symlink depending on which version we upgrade +from (pre and post usrmove). + + -- Michael Biebl Tue, 01 Oct 2024 13:18:36 +0200 + firmware-sof (2024.06-1) unstable; urgency=medium * Improvements to packaging as recommended by Vincent Bernat diff -Nru firmware-sof-2024.06/debian/firmware-sof-signed.maintscript firmware-sof-2024.06/debian/firmware-sof-signed.maintscript --- firmware-sof-2024.06/debian/firmware-sof-signed.maintscript 2024-09-09 20:55:13.0 +0200 +++ firmware-sof-2024.06/debian/firmware-sof-signed.maintscript 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ - -dir_to_symlink /usr/lib/firmware/intel/sof-ace-tplg sof-ipc4-tplg 2024.06-1~ diff -Nru firmware-sof-2024.06/debian/firmware-sof-signed.postinst firmware-sof-2024.06/debian/firmware-sof-signed.postinst --- firmware-sof-2024.06/debian/firmware-sof-signed.postinst1970-01-01 01:00:00.0 +0100 +++ firmware-sof-2024.06/debian/firmware-sof-signed.postinst2024-10-01 13:18:36.0 +0200 @@ -0,0 +1,11 @@ +#!/bin/sh +set -e + +if dpkg --compare-versions "$2" lt "2023.12.1-1.1"; then +FWPATH=/lib/firmware/intel/sof-ace-tplg +else +FWPATH=/usr/lib/firmware/intel/sof-ace-tplg +fi +dpkg-maintscript-helper dir_to_symlink $FWPATH sof-ipc4-tplg "2024.06-1~" -- "$@" + +#DEBHELPER# diff -Nru firmware-sof-2024.06/debian/firmware-sof-signed.postrm firmware-sof-2024.06/debian/firmware-sof-signed.postrm --- firmware-sof-2024.06/debian/firmware-sof-signed.postrm 1970-01-01 01:00:00.0 +0100 +++ firmware-sof-2024.06/debian/firmware-sof-signed.postrm 2024-10-01 13:18:36.0 +0200 @@ -0,0 +1,11 @@ +#!/bin/sh +set -e + +if dpkg --compare-versions "$2" lt "2023.12.1-1.1"; then +FWPATH=/lib/firmware/intel/sof-ace-tplg +else +FWPATH=/usr/lib/firmware/intel/sof-ace-tplg +fi +dpkg-maintscript-helper dir_to_symlink $FWPATH sof-ipc4-tplg "2024.06-1~" -- "$@" + +#DEBHELPER# diff -Nru firmware-sof-2024.06/debian/firmware-sof-signed.preinst firmware-sof-2024.06/debian/firmware-sof-signed.preinst --- firmware-sof-2024.06/debian/firmware-sof-signed.preinst 1970-01-01 01:00:00.0 +0100 +++ firmware-sof-2024.06/debian/firmware-sof-signed.preinst 2024-10-01 13:18:36.0 +0200 @@ -0,0 +1,11 @@ +#!/bin/sh +set -e + +if dpkg --compare-versions "$2" lt "2023.12.1-1.1"; then +FWPATH=/lib/firmware/intel/sof-ace-tplg +else +FWPATH=/usr/lib/firmware/intel/sof-ace-tplg +fi +dpkg-maintscript-helper dir_to_symlink $FWPATH sof-ipc4-tplg "2024.06-1~" -- "$@" + +#DEBHELPER# diff -Nru firmware-sof-2024.06/debian/firmware-sof-signed.prerm firmware-sof-2024.06/debian/firmware-sof-signed.prerm --- firmware-sof-2024.06/debian/firmware-sof-signed.prerm 1970-01-01 01:00:00.0 +0100 +++ firmware-sof-2024.06/debian/firmware-sof-signed.prerm 2024-10-01 13:18:36.0 +0200 @@ -0,0 +1,11 @@ +#!/bin/sh +set -e + +if dpkg --compare-versions "$2" lt "2023.12.1-1.1"; then +FWPATH=/lib/firmware/intel/sof-ace-tplg +else +FWPATH=/usr/lib/firmware/intel/sof-ace-tplg +fi +dpkg-maintscript-helper dir_to_symlink $FWPATH sof-ipc4-tplg "2024.06-1~" -- "$@" + +#DEBHELPER# OpenPGP_signature.asc Description: OpenPGP digital signature
Re: dpkg-maintscript-helper and usrmerge
Thanks Michael On Tue, Oct 1, 2024, at 7:44 AM, Michael Biebl wrote: > Am 01.10.24 um 12:17 schrieb Michael Biebl: >> Am 30.09.24 um 18:53 schrieb Mark Pearson: >>> The firmware-sof-signed 2024.06 package: >>> https://packages.debian.org/trixie/firmware-sof-signed >>> >>> In particular the sof-ipc4-tplg package that is being converted from a >>> directory to a symlink. >>> >>> The dpkg-maintscript-helper complains about /usr/lib/firmware/intel/ >>> sof-ace-tplg (and it's contents) not being owned by the package - >>> because they were all previously under /lib. >>> I suspect this is more of a special case, so would like to see a few more details. >>> >>> Holler if you need anything else. >> >> I test upgraded firmware-sof-signed from bookworm to trixie. The >> bookworm chroot was usrmerged. >> > > Ok, I see the problem now. > > The issue is, that the path used in dir_to_symlink changed pre and post > usrmove. I don't think you can express that via a .maintscript file. > > The attached debdiff should do. > This looks good to me. Just to confirm with an expert - I also have this MR for the issue: https://salsa.debian.org/mpearson/firmware-sof/-/merge_requests/7/diffs?commit_id=e25d24fbbb99d8416eef2eb51bf3f1a84ce54fbe But I think your solution is cleaner - in my limited knowledge/experience. I'm going ahead and testing it, but if you have any feedback or thoughts let me know. Many thanks for the help Mark
Bug#1083104: RFH: multipath-tools -- maintain multipath block device access
Package: wnpp Severity: normal X-Debbugs-Cc: multipath-to...@packages.debian.org, debian-devel@lists.debian.org, team+linux-blo...@tracker.debian.org, a...@debian.org, r...@debian.org, mitchell.dzur...@canonical.com Control: affects -1 + src:multipath-tools I request assistance with maintaining the multipath-tools package. multipath-tools has Ritesh, Guido and me as maintainers. I think Guido has moved on to other important topics in Debian, and Ritesh is busy. I myself no longer have test hardware that uses a multipath setup, so it's become harder for me to really test and work on the packaging. There is a new upstream version (0.10.0) that needs packaging. Don't know yet if it will just work or if it will need a lot of changes. Anyway, multipath-tools needs to continue existing for a few more years until the world has moved on to exclusive use of NVMe and NVMe-oF. Until then, all sorts of setup need multipath-tools. There is a kernel component (dm-multipath) and some integration with lvm2 and systemd that one should also at least kinda know about. Whoever wants to help, probably best to join the salsa group and start making changes. Thanks, Chris The package description is: These tools are in charge of maintaining the disk multipath device maps and react to path and map events. . If you install this package you may have to change the way you address block devices. See README.Debian for details.
Re: dpkg-maintscript-helper and usrmerge
Am 01.10.24 um 20:15 schrieb Mark Pearson: On Tue, Oct 1, 2024, at 7:44 AM, Michael Biebl wrote: Am 01.10.24 um 12:17 schrieb Michael Biebl: The issue is, that the path used in dir_to_symlink changed pre and post usrmove. I don't think you can express that via a .maintscript file. The attached debdiff should do. This looks good to me. Just to confirm with an expert - I also have this MR for the issue: https://salsa.debian.org/mpearson/firmware-sof/-/merge_requests/7/diffs?commit_id=e25d24fbbb99d8416eef2eb51bf3f1a84ce54fbe But I think your solution is cleaner - in my limited knowledge/experience. I'm going ahead and testing it, but if you have any feedback or thoughts let me know. Thanks for the reference. The lintian-overrides is probably a good idea. You might want to pull that (and adapt it, regarding the comment and the the path) from that MR. That said, I prefer my solution, as it is more obvious to me what it does and why. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1083111: ITP: git-cinnabar -- Git remote helper to interact with mercurial repositories
Package: wnpp Severity: wishlist Owner: Mike Hommey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: git-cinnabar Version : 0.7.0~beta.2 Upstream Contact: Mike Hommey * URL : https://github.com/glandium/git-cinnabar * License : MPL-2.0 and GPL-2.0 Programming Lang: Rust, C Description : Git remote helper to interact with mercurial repositories git-cinnabar is a git remote helper to interact with mercurial repositories. Contrary to other such helpers, such as git-remote-hg, it doesn't use a local mercurial clone under the hood, and doesn't require mercurial (except to access local mercurial repositories). The package will be maintained as part of the debcargo-conf repository from the Debian Rust team. Mike
Re: dpkg-maintscript-helper and usrmerge
On Tue, Oct 1, 2024, at 4:32 PM, Michael Biebl wrote: > Am 01.10.24 um 20:15 schrieb Mark Pearson: >> >> On Tue, Oct 1, 2024, at 7:44 AM, Michael Biebl wrote: >>> Am 01.10.24 um 12:17 schrieb Michael Biebl: > >>> The issue is, that the path used in dir_to_symlink changed pre and post >>> usrmove. I don't think you can express that via a .maintscript file. >>> >>> The attached debdiff should do. >>> >> This looks good to me. >> >> Just to confirm with an expert - I also have this MR for the issue: >> https://salsa.debian.org/mpearson/firmware-sof/-/merge_requests/7/diffs?commit_id=e25d24fbbb99d8416eef2eb51bf3f1a84ce54fbe >> >> But I think your solution is cleaner - in my limited knowledge/experience. >> >> I'm going ahead and testing it, but if you have any feedback or thoughts let >> me know. > > Thanks for the reference. > The lintian-overrides is probably a good idea. You might want to pull > that (and adapt it, regarding the comment and the the path) from that MR. > That said, I prefer my solution, as it is more obvious to me what it > does and why. > Ack - will do. I did some testing this afternoon, of your version, and it looked good. Thanks again Mark
