Re: Has anyone seen Yann Amar (src:bilibop)?
Hi, (fully quoting so that Yann Amar gets the context of my email) наб (2024-10-25): > Hi; > > The salvage team largely operates by QAing packages highlighted by BOTD > http://blends.debian.net/botd/botd.html > which means ones with non-wontfix bugs & not uploaded by maintainer for 5 > years > & Standards-Version < 4 & no/invalid VCS. > > This has a high hit-rate, and I've noticed that many of these packages' > maintainers only maintain one package. Thus, I'm evaluating > the ~1000 single-package maintainers' packages under the same lens > (the hit-rate is much lower and my query is not good). > > Yesterday I got to Yann Amar , > who maintains src:bilibop. > > tracker.d.o shows a history of very regular uploads, > both big and small, from 2013-09-21 up to 0.6.3 @ 2021-02-09. > > https://bugs.debian.org/src:bilibop lists, chronologically: > #983396 2021-02 bilibop: [INTL:pt_BR] Brazilian Portuguese debconf > templates translation > #995691 2021-10 [INTL:sv] Swedish strings for bilibop debconf > #1002939 2022-01 bilibop: [INTL:it] Italian translation of debconf messages > #1025592 2022-12 bilibop-rules: suggests transitional policykit-1 package > #1059552 2023-12 bilibop: isolation-machine autopkgtest (lockfs) fails on > bookworm and newer > > The last commit in the VCS > https://un.poivron.org/~quidame/git/bilibop.git/ > from 2021-03-08 is d/changelog for 0.6.4 with #983396 applied. > This matches the last-modified date on > https://un.poivron.org/~quidame/git/ > and is the latest out of all repositories there. > > The homepage/wiki all has last-updated dates from juin 2013. > I don't see any other posts under this name on lists.d.o. > contact/ says quidame on OFTC, and that user doesn't seem to be online. > I haven't linked this user to any other on-line medium. > > I'd characterise this behaviour as highly uncharacteristic and worrying > (I may just be primed after >https://github.com/cybernoid/archivemount/issues/29 > but early 2021 is not much different to excess deaths from late 2020 :/). > > Has anyone seen Yann Amar? I have tried out of band methods and I've just received sign of life :) I'll now put Yann Amar in touch with the person who's currently responsible for sponsoring uploads of src:bilibop. Cheers, -- intrigeri
Re: Upstreams with "official" tarballs differing from their git
Le 2025-02-16 21:03, Julien Puydt a écrit : - the previous version used %%VERSION_NUM%% in only three places, the new one uses it more, so it broke my previous hack -- ; As a matter of best practices, this should probably be defined in a single place and not "hardcoded" multiple times with templating. - there are other things than the substitutions done by dune when compiling the package, which do not break the build, but will break some depending packages later on with strange and misleading errors. Do you mean here that using the "official" tbz source tarballs for builds outside of a git tree will result in these errors? If so, that's a serious upstream build tool issue IMO. As mentioned somewhere in the thread I proposed to dune upstream a simple mechanism to bypass this git reliance issue, which will make packaging much cleaner. That's probably the way to go here. I would also suggest modifying dune-release so the git release tags end up with the substitutions already applied, to make it possible to simply export them and build them outside of a git tree. Cheers, -- Julien Plissonneau Duquène
Re: Upstreams with "official" tarballs differing from their git
On 2025-02-17 08:25:03 +0800 (+0800), Sean Whitton wrote: > On Sun 16 Feb 2025 at 06:18am -06, rhys wrote: > > > The potential for additional function is not relevant. > > > > If the upstream intends to distribute it with a tarball, that's > > the "golden" package that downstream should base code upon. > > The Debian project officially disagrees with you. > > The preferred form for modification, which is what NEW cares about, is > determined by upstream's actual practices, not by their fiat. > > We frequently reject packages from NEW because we have minified files; > we add the source to debian/missing-sources/. Unfortunately Debian is also very conflicted on this point. Debian has, for legal and logistical reasons, decided that it cannot distribute upstream Git repositories as its source packages, and instead chooses to try to condense upstream's preferred form for modification (back) into source tarballs. In some cases, this condensing loses data that upstream considers important, even at times things referred to in copyright licenses. The irony here is that some of those upstreams do publish source tarballs where that data is extracted from their Git repositories so it can be included correctly, but package maintainers need to be careful to run the same source tarball build process for the basis of the Debian source package in those cases and not just pretend that the _files_ tracked in Git are the same as upstream's preferred form for modification. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Packages with a history of security issues and whose packaged version is not up to date
On Mon, Feb 17, 2025 at 9:14 PM Santiago Ruano Rincón wrote: > There are two numbers accompanying the source packages: the amount of > currently open security issues in sid, and the number of security issues > that have been present in Debian ever (as you mention). > I've been biting my tongue a bit here but there's an implicit third number (which no one is able to actually compute) here: number of actual security issues that need attention. CVEs are not perfect. CVE count is, charitably, a proxy for how much security attention / research it gets (hopefully that is, in turn, a proxy for how important a package is). Not so charitably, it's perhaps a proxy for how many people who want to build a reputation as an expert have spent time finding something that would pass minimal scrutiny as a security issue. There are plenty of security issues that are solved via normal bugfixes by people who never realize the security implications of their bugfixes. In important security sensitive places, too! Updating to the latest upstreams is a good idea for lots of reasons, but I don't totally understand the nexus to CVE here. Don't let me dissuade you from doing good work here, but I reckon CVE counting is likely going to lead to a lot of very weird non-security related biases which you may or may not actually want. FWIW this will solve one real problem: Lots of companies complain endlessly and mindlessly about CVEs based on package version(s) without regards to the issue being exploitable or even reachable (or built into the binary, in some cases!). Closing CVEs out will no doubt make them complain less, which sounds nice. Paul
Re: Packages with a history of security issues and whose packaged version is not up to date
El 16/02/25 a las 21:15, Marco d'Itri escribió: > On Feb 14, Colin Watson wrote: > > > But it doesn't. Santiago's using the data from the security tracker to > > determine whether CVEs are open. > And in the case of one of my own packages these CVEs have not yet been > fixed upstream, not even in an unreleased branch. Yes, and those are examples of the "false positive" cases I was referring to originally. I am not aware of any way to automatically filter them, as of today. signature.asc Description: PGP signature
Re: Upstreams with "official" tarballs differing from their git
Hello, On Mon 17 Feb 2025 at 08:22am -06, rhys wrote: > "Actual practices" and "by fiat" are no different here. The former refers to what they actuall work with, the latter refers to what they claim is the preferred form of modification. These can come apart. > They do as they like with their code. Yes, just as we may :) -- Sean Whitton signature.asc Description: PGP signature
GCC-15 mass bug filing.
Hello everybody, pardon me but I do not see the GCC mass bug filing being discussed on this list before it was started. Give the scale if build failure (hundreds of failures for the Debian Med packaging team for instance), I want to question if the MBF is premature. What other information do we get apart from "most upstreams are not ready" ? Again, given the scale, Debian can not expect that the package maintainers are going to contact each upstream and send a patch. We are not paid for that. On the other hand, we also rely on "the ecosystem" to do the work by themselves so that the packages eventually start to build fine with GCC 15 them after we upgrade them to newer upstream versions. But who will close the hundreds of bugs? I mean, query the BTS, get a bug number, paste it in a changelog, etc, just to convey information about a change that did not happen in Debian ? We are not paid for that. If we want to have stats and know what is the percentage of our pakcages that adopted GCC 15 compatibility at a given point of time, mass rebuilds are enough. Salsa CI also comes to the mind. But before we reach the point that we start to track release blockers, I question if mass bug filings are a tool that makes the best use of our volunteer time? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: GCC-15 mass bug filing.
* Charles Plessy [250218 01:07]: > On the other hand, we also rely on "the ecosystem" to do the work by > themselves so that the packages eventually start to build fine with GCC > 15 them after we upgrade them to newer upstream versions. But who will > close the hundreds of bugs? I mean, query the BTS, get a bug number, > paste it in a changelog, etc, just to convey information about a change > that did not happen in Debian ? We are not paid for that. So you are saying you are not checking the BTS for bugs that upstream fixed in new upstream version, before uploading a new upstream version? Chris
Re: GCC-15 mass bug filing.
Le 18 février 2025 01:06:53 GMT+01:00, Charles Plessy a écrit : >Hello everybody, > >pardon me but I do not see the GCC mass bug filing being discussed on >this list before it was started. > >Give the scale if build failure (hundreds of failures for the Debian Med >packaging team for instance), I want to question if the MBF is >premature. What other information do we get apart from "most upstreams >are not ready" ? Same for the Qt/KDE stack. Every package in our perimeter got a bug report due to a Qt-related failure. And it should all be fixed in the upcoming Qt upload as far as we know. >Again, given the scale, Debian can not expect that the package >maintainers are going to contact each upstream and send a patch. We are >not paid for that. At this scale even managing the Debian bugs seems like a waste of time. I don't think I'll touch mine. Happy hacking, -- Aurélien
Re: Upstreams with "official" tarballs differing from their git
Hi, Le lundi 17 février 2025 à 10:07 +0100, Julien Plissonneau Duquène a écrit : > Le 2025-02-16 21:03, Julien Puydt a écrit : > > > > - the previous version used %%VERSION_NUM%% in only three places, > > the > > new one uses it more, so it broke my previous hack -- ; > > As a matter of best practices, this should probably be defined in a > single place and not "hardcoded" multiple times with templating. Yes. Most upstream have little clue on what a best practice is, and need to be explained at length. That's part of the job of a DD... > > - there are other things than the substitutions done by dune when > > compiling the package, which do not break the build, but will break > > some depending packages later on with strange and misleading > > errors. > > Do you mean here that using the "official" tbz source tarballs for > builds outside of a git tree will result in these errors? If so, > that's a serious upstream build tool issue IMO. No, I mean the build tool takes the git repo with the .git/ directory, and gives a tarball without .git/ where substitutions have been made (those can be recognized because they look like %%FOO_BAR%%) *and* some code added in various places (those can't be recognized beforehand). Their .tbz is working nicely -- but it isn't source anymore! > > As mentioned somewhere in the thread I proposed to dune upstream a > > simple mechanism to bypass this git reliance issue, which will make > > packaging much cleaner. > > That's probably the way to go here. I would also suggest modifying > dune-release so the git release tags end up with the substitutions > already applied, to make it possible to simply export them and build > them outside of a git tree. I think the way to go is the one I proposed in my upstream bug report ( https://github.com/ocaml/dune/issues/11484 ) and which Stéphane Glondu proposed a PR for ( https://github.com/ocaml/dune/pull/11485 ). It hasn't been accepted yet, but there's hope. Cheers, J.Puydt
Re: Packages with a history of security issues and whose packaged version is not up to date
El 13/02/25 a las 21:57, Paul Gevers escribió: > Hi, > > On 13-02-2025 20:21, Santiago Ruano Rincón wrote: > > Any thoughts? > > > You might also want to somehow take activity on the package into account. > E.g. cacti (that I am nearly the only uploader for) has seen an update for > CVE's only last week. I don't think I need (nor would I appreciate) more > naging. Thanks for this comment, acknowledged. > How do you envision *using* this list, except having this discussion and > sharing a dd-list as suggested by Jonas? File wishlist bugs against the > packages if they don't exist yet (taking the first paragraph into account > too)? I think that reporting bugs would make sense, and it is the first idea that naturally came up to my mind. In any case, I was not thinking in blindly running mass-bug filing. Other than to take into account recent activity, I think it is important to look for possible reasons for not packaging the version reported by uscan, before filing a bug report. Maintainers may have different methods to keep a package up-to-date, e.g. (again) nginx, for which keeping ABI/API stable is also important. So, I was *not* planing to file bugs for all of the packages listed there. To answer other comments in this thread, yes, more filtering would enhance this list. I acknowledge that the current script and list is not perfect. Cheers, -- Santiago signature.asc Description: PGP signature
Re: Packages with a history of security issues and whose packaged version is not up to date
El 15/02/25 a las 18:36, Chris Hofstaedtler escribió: > * Colin Watson [250214 18:13]: > > On Fri, Feb 14, 2025 at 03:28:35PM +0100, Marc Haber wrote: > > > Especially if the list just goes the (wrong) way of so many commercial > > > security tools and/or consultants who just compare version numbers and > > > flag our stable versions as vulnerable regardless whether we have > > > patched vulnerabilities or not. > > > > But it doesn't. Santiago's using the data from the security tracker to > > determine whether CVEs are open. > > I understood Santiago looked at all packages that ever had a > security issue reported. The two of my packages in the list would > support this interpretation. > > I don't see how this is a meaningful prioritization. There are two numbers accompanying the source packages: the amount of currently open security issues in sid, and the number of security issues that have been present in Debian ever (as you mention). One of my main motivations for creating this list is the *hypothesis* that reducing the gap with upstream will make the work easier for the people backporting patches during the Debian release life cycle. Let's take paramiko as example (which was on the list of packages with no open issues, but with some cve history, and because the version in sid was 3.5.0 while upstream had released 3.5.1), and let's suppose that during the time trixie is supported, there is a new CVE about how paramiko handles private keys. Suppose that to fix that very hypothetical issue it would be needed to backport/cherry-pick the padding-related changes made in 3.5.1: https://github.com/paramiko/paramiko/commit/3acc7906d25189b11219a7472e1532fa3ad9a1d9 If 3.5.1 is shipped in trixie, the related code wouldn't have to be backported, so the patch would be smaller (and hopefully easier). And the code would be exposed more time via the unstable to testing migration than with a regular security update, which would reduce the probability of introducing regressions. Of course, I would expect that similar examples would make much more sense for packages with a more important gap between sid and unstable. If I have a limited amount of time to spend on Debian, I would like to prioritize (thanks Colin for communicating this better than me) the things to do where I could offer my help. I don't have any way to tell which packages will have new security issues during trixie, so I assume that packages with a history of security issues have more chances to need fixes. And so, I prioritize my Debian time looking at them. Cheers, -- Santiago signature.asc Description: PGP signature
