Package: wnpp
Severity: wishlist
Owner: Kathara Sasikumar
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: sphinx-togglebutton
Version : 0.3.2
Upstream Contact: Chris Holdgraf
* URL : https://github.com/executablebooks/sphinx-togglebutton
* License
Package: wnpp
Severity: wishlist
Owner: Salvo 'LtWorf' Tomaselli
X-Debbugs-Cc: debian-devel@lists.debian.org, ltw...@debian.org
* Package name: qrca
Version : unreleased
Upstream Contact: Jonah Brüchert
* URL : https://invent.kde.org/utilities/qrca
* License :
Package: wnpp
Severity: wishlist
Owner: Alexandre Viard
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: 81voltd
Version : 1.0.0
Upstream Contact: Richard Acayan
* URL : https://gitlab.postmarketos.org/modem/81voltd
* License : GPL2+
Programming L
> "Santiago" == Santiago Ruano Rincón writes:
Santiago> Dear Debian fellows, I am writing this email under the
Santiago> hypothesis that having the latest (or longest supported)
Santiago> upstream version in the next release will: 1. make it
Santiago> easier to provide securit
On 18/02/25 at 13:21 -, Sune Vuorela wrote:
> On 2025-02-18, Michael Biebl wrote:
> > I guess a bit of shell scripting around `bts close` would suffice?
> > That assumes of course you can somehow (automatically) determine the
> > list of packages that are fixed by that one popular library.
>
Package: wnpp
Severity: wishlist
Owner: Daniel Gröber
X-Debbugs-Cc: debian-devel@lists.debian.org, d...@darkboxed.org, Tony Finch
Hi d-devel,
I'm packaging regrettably obscure but highly useful DNS software again
(before: nsdiff). Tony really knows how to build these minimal but
exremely versa
On Tue, Feb 18, 2025, 8:56 AM Roberto C. Sánchez wrote:
> I agree that something like this effort is likely to reduce the
> occurence of that sort of thing. And, yes, CVE is probably not a great
> proxy. But Santiago has discussed this with quite a few of us on the LTS
> team at various points al
On 2025-02-18 08:55:55 -0500 (-0500), Roberto C. Sánchez wrote:
[...]
> In theory, any abnormal program behavior has the potential to carry a
> security implication. And in one project I have actually seen where
> there was a push to retroactively designate CVEs for past bug fixes that
> it turned
On Mon, Feb 17, 2025 at 09:42:21PM -0500, Paul R. Tagliamonte wrote:
>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 prox
On Mon, Feb 17, 2025 at 10:47:04PM +0100, Julien Puydt wrote:
> Yes. Most upstream have little clue on what a best practice is, and
> need to be explained at length.
TBH I basically stopped reading here, this assumption is so flawed, the
(upstream) world is way more diverse.
--
cheers,
On Tue, Feb 18, 2025 at 12:32:08PM +, Colin Watson wrote:
> I for one appreciate this sort of early warning. It's much easier to
> deal with failures like this promptly before they become a serious
> problem, rather than having to disentangle things later when several
> different failures have
Package: wnpp
Severity: wishlist
Owner: Pete Ryland
X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-haskell-maintain...@lists.alioth.debian.org, p...@pdr.cx
* Package name: haskell-regex-pcre2
Version : 1.0.0.0
Upstream Contact: Pete Ryland
* URL : https://hackage.h
On 18.02.2025 14:32, Sune Vuorela wrote:
On 2025-02-18, Preuße Hilmar wrote:
Hello,
I have one. Should I add a usertag: gcc-15_fault_of_qt6 ?
I suggest just closing it. It does not bring any value at all.
What is the bug number in QT? Thanks!
H.
--
sigfault
OpenPGP_signature.asc
De
On 2025-02-18, Preuße Hilmar wrote:
> I have one. Should I add a usertag: gcc-15_fault_of_qt6 ?
I suggest just closing it. It does not bring any value at all.
/Sune
On 18.02.2025 14:21, Sune Vuorela wrote:
On 2025-02-18, Michael Biebl wrote:
Hi
I guess a bit of shell scripting around `bts close` would suffice?
That assumes of course you can somehow (automatically) determine the
list of packages that are fixed by that one popular library.
I'm not sure
On 2025-02-18, Michael Biebl wrote:
> I guess a bit of shell scripting around `bts close` would suffice?
> That assumes of course you can somehow (automatically) determine the
> list of packages that are fixed by that one popular library.
I'm not sure I'm up to scripting it, but all sources wher
Hi
Am 18.02.25 um 13:34 schrieb Sune Vuorela:
On 2025-02-18, Matthias Klose wrote:
This is nothing new. See https://wiki.debian.org/ToolChain for all bugs
filed since GCC 4.9. Do you really want to have a yearly discussion to
file these bugs? The difference this year is having more than doub
Antonio Terceiro, le mar. 18 févr. 2025 10:00:18 -0300, a ecrit:
> On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> > Give the scale if build failure (hundreds of failures for the Debian Med
> > packaging team for instance),
> I don't think that "OMG my packages have bugs and I ne
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> 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 instanc
On 2025-02-18, Matthias Klose wrote:
> This is nothing new. See https://wiki.debian.org/ToolChain for all bugs
> filed since GCC 4.9. Do you really want to have a yearly discussion to
> file these bugs? The difference this year is having more than double of
> the bug reports compared to GCC 1
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> 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
Am 18.02.25 um 11:05 schrieb Andrey Rakhmatullin:
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
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.
Yes, Debian only expects
On 18.02.25 10:21, Marco d'Itri wrote:
I think that adding a GCC 15 build to the standard Salsa CI pipeline
would have been a nicer early warning than a MBF.
Maybe this could be considered by the time GCC 16 will start getting
ready to be useful?
are you volunteering? You could even do that now
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> 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.
Yes, Debian only expects that such bugs are forwarded upstream, not
that
Hi,
Le 2025-02-17 22:47, Julien Puydt a écrit :
Their .tbz is working nicely -- but it isn't source anymore!
I think that we disagree on this one. Here the extent of source code and
build files changes between the .tbz and the git repository is
reasonably small and can be compared to what h
On Feb 18, Charles Plessy wrote:
> 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.
We are not paid for anything at all, to be fair...
I think that we are expected to forward most bugs to
Hi,
On 2/18/25 00:21, Jeremy Stanley wrote:
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.
If we "c
On 18.02.25 01:06, Charles Plessy wrote:
Hello everybody,
pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.
This is nothing new. See https://wiki.debian.org/ToolChain for all bugs
filed since GCC 4.9. Do you really want to have a yearly di
28 matches
Mail list logo
