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
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
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
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 numbe
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 l
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)
* 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 t
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
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 pr
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
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 t
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
>
12 matches
Mail list logo
