Bug#1057636: ITP: swift-tools -- Swift cluster cli helpers utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: swift-tools Version : 0.0.1 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/swift-tools * License : Apache-2.0 Programming Lang: Python Description : Swift cluster cli helpers utilities This package contains a set of utilities to help managing Swift cluster. It helps, for example: * check rebalance status * check status of the cluster * check max oldest completion
Re: Migration blocked
On 12/5/23 06:52, Yadd wrote: Hi all, I uploaded src:node-proxy-agents into unstable, which is the new source of node-proxy and node-https-proxy-agent. This package didn't migrate but I don't understand the reason of this block. The tracker[1] reports regressions on node-proxy and node-https-proxy-agent (which are replaced), and related logs contains "ERROR: erroneous package: rules extract failed with exit code 1". How can I fix this problem ? Best regards, Yadd [1]: https://tracker.debian.org/pkg/node-proxy-agents Hi, can someone help me here ?
Re: Migration blocked
Hi, On 05-12-2023 03:52, Yadd wrote: I uploaded src:node-proxy-agents into unstable, which is the new source of node-proxy and node-https-proxy-agent. This package didn't migrate but I don't understand the reason of this block. The tracker[1] reports regressions on node-proxy and node-https-proxy-agent (which are replaced), and related logs contains "ERROR: erroneous package: rules extract failed with exit code 1". How can I fix this problem ? To be fair, I don't think you can unless you like to work on britney2 [2] and/or autopkgtest [3]. This is a corner case that our software doesn't handle correctly. So, the right course of action in a case like this is to contact the Release Team (I'm a member, so consider it done). *Maybe* a removal from unstable of src:node-https-proxy-agent and src:node-proxy would help, but I'm not convinced. Those sources should eventually go away automatically [4] (from your point of view). Paul [1]: https://tracker.debian.org/pkg/node-proxy-agents [2] https://salsa.debian.org/release-team/britney2/ [3] https://salsa.debian.org/ci-team/autopkgtest/ [4] https://ftp-master.debian.org/cruft-report-daily.txt OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Preparing for Python 3.12
Hi Matthias (2023.12.03_14:03:44_+) > We probably will see some Python related build failures while binNMUing > around 600 packages to add 3.12 as a supported version. If you see builds > failing because of a missing 3.12 extension, please just wait a few days > until all the binNMUs are done. > > For the progress, see (ignoring the 'unknown' status) > https://release.debian.org/transitions/html/python3.12-add.html This is a great time for new Python Team contributors to get involved in helping to support Python 3.12. This is a time when upstream Python knowledge can be more helpful than Debian packaging experience. Look go down the list of packages and investigate the ones with a red line. Either they have failed to build (top of the list) or they haven't been built against 3.12 yet (bottom of the list). As we investigate these, we'll file FTBFS bugs against them (which usually show up on buildd.debian.org, below the builds). Usually the process is: 1. Read the bug to see the investigation so far. 2. Check the upstream bugtracker for related bugs. 3. See if there is a new upstream release or commit that promises to support Python 3.12 (or whatever the issue is). 4. Report back on the bug 5. Prepare an upload. We're mostly coordinating in #debian-python on IRC. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Signature strength of .dsc
On Fri, 1 Dec 2023 at 00:20, Dimitri John Ledkov wrote: > > Hi, > > Currently dak requires signatures on .changes & .dsc uploads. .changes with > signatures are publicly announced and then .dsc are published in the archive > with signatures. .changes references .dsc. > > All .dsc have Checksums-Sha256 for the files they reference, .dsc itself can > be verified through strong checksum in Sources metadata, chained via > InRelease to the strong debian archive key signature. > > The same is not true for signatures on .dsc themselves. Majority of .dsc use > at least sha256 and can be successfully verified. > > But some use weak hash: > 5 dsc signed using Hash: RIPEMD160 > 152 dsc signed using Hash: SHA1 > May I file a bug report to lintian to consider such a pedantic check (when it can) to warn about using such legacy algo functions? May I also do a mass bug file against the above set of packages, at wishlist priority to nudge maintainers (or QA or Janitor) to make an upload? ideally bundled with any other reasonable modernisations. As such an algorithm indicates that the package is likely to be either very stable or in potential need of a bit of TLC ? -- Regards, Dimitri.
Re: Migration blocked
On 12/6/23 23:02, Paul Gevers wrote: Hi, On 05-12-2023 03:52, Yadd wrote: I uploaded src:node-proxy-agents into unstable, which is the new source of node-proxy and node-https-proxy-agent. This package didn't migrate but I don't understand the reason of this block. The tracker[1] reports regressions on node-proxy and node-https-proxy-agent (which are replaced), and related logs contains "ERROR: erroneous package: rules extract failed with exit code 1". How can I fix this problem ? To be fair, I don't think you can unless you like to work on britney2 [2] and/or autopkgtest [3]. This is a corner case that our software doesn't handle correctly. So, the right course of action in a case like this is to contact the Release Team (I'm a member, so consider it done). *Maybe* a removal from unstable of src:node-https-proxy-agent and src:node-proxy would help, but I'm not convinced. Those sources should eventually go away automatically [4] (from your point of view). Paul Thank a lot Paul !
