Package: wnpp
Severity: wishlist
Owner: Marcio de Souza Oliveira
* Package name: cupp
Version : 0.0+20160624.git07f9b8-1
Upstream Author : Mebus, Muris Kurgas, Abhro, Andrea Giacomo, Bosko Petrovic
* URL : https://github.com/Mebus/cupp
* License : GPL-3+
Pro
Xen writes:
> I would simply suggest that in principle you keep bugs open until it
> no longer exists.
One reason bug reports get closed is because the report is far too vague
to even know *whether* it exists, or under what conditions it would be
considered fixed.
That action is IMO much better
Package: wnpp
Followup-For: Bug #706656
Owner: Gregor Riepl
Hello, I've been using Cura (new Cura, not the legacy one) for a while, and
decided that it would be a good idea to package it up for Debian.
Upstream does not make this particularly easy, but thanks to the use of
standard build tools,
Adrian Bunk writes ("Re: Debian does not have customers"):
> If you want to be honest, you have to tell users that they shouldn't
> waste their time on reporting bugs against the ancient versions of
> such packages in stable.
> It is not likely that anyone will ever look at these bugs - they are
>
On Wed, Sep 21, 2016 at 03:13:32PM +0200, Xen wrote:
> >A closed bug is presumptively a fixed bug (because bugs which have been
> >fixed get closed).
> >
> >An open bug is presumptively a non-fixed bug.
> >
> >Therefore, to close a bug which has not been fixed is to pretend that
> >the problem repo
On Wed, Sep 21, 2016 at 12:50:41PM -0700, Russ Allbery wrote:
>...
> But still, despite all of those caveats, I do think there are a few things
> that are fairly clear-cut. If the package has 3,000 open bugs, just close
> out the unactionable reports in some polite and constructive way. At that
>
Quoting Henrique de Moraes Holschuh :
On Wed, 21 Sep 2016, john.k...@vfemail.net wrote:
Is the reason for closing the bug 837459 appropriate here? The bug is
still
here and no backported version.
I believe it was appropriately closed, yes.
#837459 is not a request for a backport. Instead,
Adrian Bunk writes:
> "no one is ever going to look at the bug again" is actually impossible
> to prove for a project like Debian - some new Debian developer or even
> some new upstream developer might actually look at it tomorrow or in a
> few years.
Yeah, I know, and this is a valid point, and
On Wed, Sep 21, 2016 at 10:56:10AM -0700, Russ Allbery wrote:
>...
> If no one is ever going to look at the bug again, just close it. It feels
> more confrontational, but it's far more honest, and it doesn't create
> unrealistic expectations.
>...
"no one is ever going to look at the bug again" i
On Wed, 21 Sep 2016, Henrique de Moraes Holschuh wrote:
> for that backport, and refering to bug #836459...
Typo. Make that bug #837459...
--
Henrique Holschuh
On Wed, 21 Sep 2016, john.k...@vfemail.net wrote:
> Is the reason for closing the bug 837459 appropriate here? The bug is still
> here and no backported version.
I believe it was appropriately closed, yes.
#837459 is not a request for a backport. Instead, it is a bug about
something that was alr
On Wed, 21 Sep 2016, john.k...@vfemail.net wrote:
> Is the reason for closing the bug 837459 appropriate here? The bug is still
> here and no backported version.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837459
This bug is fixed in unstable and testing, but is currently marked as
ope
Package: wnpp
Severity: wishlist
Owner: Lev Lamberov
* Package name: elpa-epc
Version : 0.1.1
Upstream Author : Masashi Sakurai
* URL : https://github.com/kiwanami/emacs-epc
* License : GPL-3+
Programming Lang: Emacs Lisp, Perl
Description : RPC stack
Xen writes:
> I would simply suggest that in principle you keep bugs open until it no
> longer exists. But that you introduce a different open state other than
> closed that will communicate "has been looked at, is not capable of
> being solved right now". This could be "pending" or "held" or
> "
Hello,
Is the reason for closing the bug 837459 appropriate here? The bug is still
here and no backported version.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837459
Best wishes,
John
-
ONLY AT VFEmail! - Use our Metadata Mitigator to kee
Package: wnpp
Severity: wishlist
Owner: Sean Whitton
* Package name: zxcvbn-c
Version : 0.20150102
Upstream Author : Tony Evans
* URL : https://github.com/tsyrogit/zxcvbn-c
* License : BSD-3-clause
Programming Lang: C/C++
Description : C/C++ implementat
Package: wnpp
Severity: wishlist
Owner: Markus Koschany
* Package name: fifechan
Version : 0.1.2
Upstream Author : fifechan team
* URL : https://github.com/fifengine/fifechan
* License : LGPL-2.1, BSD-3-clause, Boost-1.0
Programming Lang: C++
Description
The Wanderer schreef op 21-09-2016 4:58:
A closed bug is presumptively a fixed bug (because bugs which have been
fixed get closed).
An open bug is presumptively a non-fixed bug.
Therefore, to close a bug which has not been fixed is to pretend that
the problem reported in that bug has been fixe
Russ Allbery schreef op 20-09-2016 1:15:
Bart Schouten writes:
I am just going to respond point by point. I was not merely talking
about open source here.
But I was. :) I'm not particularly interested in talking about
anything
else, since that's the point of this discussion: Debian as a f
Package: wnpp
Severity: wishlist
Owner: Ximin Luo
* Package name: python-unidiff
Version : 0.5.2+git7
Upstream Author : Matias Bordese
* URL : https://github.com/matiasb/python-unidiff/issues
* License : MIT
Programming Lang: Python
Description : Unifi
On 09/21/2016 08:41 AM, Riku Voipio wrote:
> AFAIK Address space randomizing is not really helpful on 32 bit
> architectures - there is just not that many places to randomize to[1].
Well, sure, but there's still a huge difference in an explot with
100% reliability, or an exploit that will just cr
On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
> Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures. That said, you will be notified if
> that defaul
22 matches
Mail list logo
