Re: Epoch change for cctools
On 12/10/2024 10:18, Andreas Metzler wrote: On 2024-10-12 Alastair McKinstry wrote: Hi, cctools is at version 1:9.9 due to an error in 2021. [...] Looks like a typo, afaict cctools currently has *no* epoch, i.e. equivalent to 0:9.9. cu Andreas Thanks, my error. I had presumed a default epoch of 1. Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Re: Epoch change for cctools
On 2024-10-12 Alastair McKinstry wrote: > On 12/10/2024 10:18, Andreas Metzler wrote: > > On 2024-10-12 Alastair McKinstry wrote: > > > Hi, > > > cctools is at version 1:9.9 due to an error in 2021. > > [...] > > > > Looks like a typo, afaict cctools currently has *no* epoch, i.e. > > equivalent to 0:9.9. > > > > cu Andreas > Thanks, my error. I had presumed a default epoch of 1. Hello, thanks for confirming. Given that upstream versions are unlikely to increase enough to catch up with the Debian numbering soon /I/ agree that adding a epoch is indeed the best way forward. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1084997: ITP: python-iso639 -- ISO 639 language codes, names, and other associated information
Package: wnpp Severity: wishlist Owner: Jeffrey Ratcliffe X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-iso639 Version : 2024.4.27 Upstream Contact: Jackson L. Lee * URL : https://github.com/jacklonlee/iso639 * License : Apache-2.0 Programming Lang: Python Description : ISO 639 language codes, names, and other associated information * A representation of languages mapped across ISO 639-1, 639-2, and 639-3. * Functionality to "guess" what a language is for a given unknown language code or name. This is a new dependency of gscan2pdf. I will be maintaining it as part of the Debian Python Team
Re: Are 'package autoremoval emails' using very old bts data?
Hi, On 12/10/2024 16:58, Richard Lewis wrote: I couldnt work out where to ask this: Are emails about packages being removed from testing generated using stale data on what bugs are open? There are known recent issues with the freshness of the udd representation of the bts due to infrastructure issues. The root cause hasn't been found yet. The actual autoremoval script checks for the age of the information and skips the removal if the age is too old (> 1 day), but the mailer isn't that smart. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: List of not-packaged depends
On Oct 12, 2024 3:02 PM, Sudip Mukherjee wrote: > > On Fri, Oct 11, 2024 at 11:01:37AM +0200, Thomas Goirand wrote: > > Hi, > > > > Having a quick look at requirements.txt VS Debian repo, to package this > > software, we would need: > > > > python3-cvss > > python3-gsutil > > python3-lib4sbom > > python3-lib4vex > > python3-packageurl > > python3-rpmfile > > Thanks for the list zigo. But the main intention of my mail was to check if > the ITP owner is still interested or not since there has been no progress > since 18 Apr 2023. > If the ITP owner is not interestd then I can do this one ( + any other > dependency) under the Debian Python team. > > I guess I will wait a week for any reply, and if there is no reply by then > from the owner I will assume the ITP owner is not interested anymore and take > over. > > > -- > Regards > Sudip At this point (ie: 6 months after the ITP), IMO you do not need to wait. Thomas
BuildProfileSpec example equivalence question
Hi, The third example on https://wiki.debian.org/BuildProfileSpec is: Build-Depends: foo In this case, the source package would build depend on foo if either both, nocheck and cross are active or if the profile nocheck is active. [...] This is fully consistent with the definitive part above it, but isn't this equivalent to the simpler Build-Depends: foo ? If so, I'd rather use a different example which does not have this confusing property. Or do I miss something here? -- Please keep me in Cc, thanks, Feri.
Re: List of not-packaged depends
On Sat, 12 Oct 2024 at 15:43, wrote: > > > On Oct 12, 2024 3:02 PM, Sudip Mukherjee wrote: > > > > On Fri, Oct 11, 2024 at 11:01:37AM +0200, Thomas Goirand wrote: > > > Hi, > > > > > > Having a quick look at requirements.txt VS Debian repo, to package this > > > software, we would need: > > > > > > python3-cvss > > > python3-gsutil > > > python3-lib4sbom > > > python3-lib4vex > > > python3-packageurl > > > python3-rpmfile > > > > Thanks for the list zigo. But the main intention of my mail was to check if > > the ITP owner is still interested or not since there has been no progress > > since 18 Apr 2023. > > If the ITP owner is not interestd then I can do this one ( + any other > > dependency) under the Debian Python team. > > > > I guess I will wait a week for any reply, and if there is no reply by then > > from the owner I will assume the ITP owner is not interested anymore and > > take over. > > > > > > -- > > Regards > > Sudip > > At this point (ie: 6 months after the ITP), IMO you do not need to wait. I am sure you meant 1 year 6 months from the ITP. :D -- Regards Sudip
Re: List of not-packaged depends
On Fri, Oct 11, 2024 at 11:01:37AM +0200, Thomas Goirand wrote: > Hi, > > Having a quick look at requirements.txt VS Debian repo, to package this > software, we would need: > > python3-cvss > python3-gsutil > python3-lib4sbom > python3-lib4vex > python3-packageurl > python3-rpmfile Thanks for the list zigo. But the main intention of my mail was to check if the ITP owner is still interested or not since there has been no progress since 18 Apr 2023. If the ITP owner is not interestd then I can do this one ( + any other dependency) under the Debian Python team. I guess I will wait a week for any reply, and if there is no reply by then from the owner I will assume the ITP owner is not interested anymore and take over. -- Regards Sudip
Are 'package autoremoval emails' using very old bts data?
I couldnt work out where to ask this: Are emails about packages being removed from testing generated using stale data on what bugs are open? (are im not complaining about the process just trying to understand it) According to https://udd.debian.org/udd-status.cgi data on bugs is updated a lot less frequently than data on testing-autoremovals, is there a reason more frequent updates of the bts data can't be done? I think this led to the following: Wed, 18 Sep 2024 08:27:03 UTC - A (completely valid) rc bug against chkrootkit 0.58b-1 was opened (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082087) - At some point a (valid) warning is produced saying that the package (0.58b-1) would be removed from testing due to this bug -- this is all as expected. (Thu, 26 Sep 2024 06:34:02 + - 0.58b-2 was uploaded with a changelog closing the bug, and other changes which meant some autopkgtests failed. This never made it to testing -- all fine, 0.58b-3 was prepared to solve that) Mon, 30 Sep 2024 14:34:02 + - 0.58b-3 was uploaded which fixed everything (https://tracker.debian.org/news/1570784/accepted-chkrootkit-058b-3-source-into-unstable/) - by coincidence, this version was just after a new glibc was uploaded, so migration to testing had to wait until that migrated -- all fine and 'expected'. So far, this all seems to be working as expected. The warning about removal of 0.58b-1 from testing was still 'valid', because testing was still affected by an rc bug. Thu, 10 Oct 2024 04:39:07 + - 0.58b-3 makes it into testing. https://tracker.debian.org/news/1574012/chkrootkit-058b-3-migrated-to-testing/ At this point, the version in testing is no longer affected by any rc bugs. The bts seems to know this. However: Fri, 11 Oct 2024 04:39:06 + - the autoremoval script sends an email saying "chkrootkit 0.58b-3 is marked for autoremoval from testing on 2024-11-08" due to it "being affected by" 1082087 I assume this is a false positive, but it's quite confusing as it seems to have got the latest version in testing correct, but is wrong about what bugs affect -- i'd assume there is always a race condition here, but 0.58b-3 was known not to be effected by that bug for well over a week. the email pointed me to https://salsa.debian.org/qa/udd/-/raw/master/udd/testing_autoremovals_gatherer.pl but it doesnt say how old the data is. I found https://udd.debian.org/udd-status.cgi which suggets info on bugs are updated less frequently than most things, but not sure that is the issue here? I assume the actual removal process would use up-to-date data?
Epoch change for cctools
Hi, cctools is at version 1:9.9 due to an error in 2021. The current version is 7.13.1 (https://github.com/cooperative-computing-lab/cctools/tags) I propose to move epoch to fix this; reaching out to debian-devel as per policy. Best regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie https://mastodon.ie/@amckinstry
Re: Epoch change for cctools
On 2024-10-12 Alastair McKinstry wrote: > Hi, > cctools is at version 1:9.9 due to an error in 2021. [...] Looks like a typo, afaict cctools currently has *no* epoch, i.e. equivalent to 0:9.9. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
