❦ 4 septembre 2016 10:13 CEST, Chris Lamb :
>> > Oh! I thought we were discussing whether it was a bug at all […] not the
>> > severity of the bug itself.
>>
>> This is why I think the issue should be discussed more broadly.
>
> To be clear, I was referring to that it was regrettable — in gener
> > Oh! I thought we were discussing whether it was a bug at all […] not the
> > severity of the bug itself.
>
> This is why I think the issue should be discussed more broadly.
To be clear, I was referring to that it was regrettable — in general — that
you would ignore any bug submitted against an
> Santiago Vila wrote:
>
> > This is not just a privacy issue but also a reproducibility issue.
[…]
> In this case, there is no reproducibility issue.
(I agree; this a different issue to the one being discussed in this
bug. Obviously, no package build should execute code downloaded from
the intern
❦ 3 septembre 2016 23:37 CEST, Chris Lamb :
>> If your bug was wishlist, I would just ignore it. It is severity serious
>> and I have to handle it. Maybe it is legitimate. Maybe not.
>
> Oh! I thought we were discussing whether it was a bug at all — hence the
> time you spent addressing whether
❦ 4 septembre 2016 01:03 CEST, Santiago Vila :
>> [...] information leak [...]
>
> This is not just a privacy issue but also a reproducibility issue.
>
> It is bad that a package leaks information to the external world,
> but it is even worse, I would say, that information from the outside
> wo
On Sat, 3 Sep 2016, Vincent Bernat wrote:
> [...] information leak [...]
This is not just a privacy issue but also a reproducibility issue.
It is bad that a package leaks information to the external world,
but it is even worse, I would say, that information from the outside
world is being used i
> If your bug was wishlist, I would just ignore it. It is severity serious
> and I have to handle it. Maybe it is legitimate. Maybe not.
Oh! I thought we were discussing whether it was a bug at all — hence the
time you spent addressing whether privacy leaking is valuable — not the
severity of the
❦ 3 septembre 2016 21:22 CEST, Chris Lamb :
>> The policy says "may not". I am not a native speaker, but for me, this
>> is not like "must not". Since you are a native speaker, I think you know
>> better: is it optional or not?
>
> May I suggest an alternative approach…? We have two cases here:
Hi Vincent,
> The policy says "may not". I am not a native speaker, but for me, this
> is not like "must not". Since you are a native speaker, I think you know
> better: is it optional or not?
May I suggest an alternative approach…? We have two cases here:
a) Debian Policy states it is a bug i
❦ 3 septembre 2016 15:46 CEST, Chris Lamb :
>> Was this MBF discussed somewhere?
>
> I don't consider it to be a MBF — I haven't been systematically working
> my way through the archive and I've really only filed a handful of bugs;
> mostly quasi-duplicates due to Sphinx stuff (which is arguabl
Hi Vincent,
> Was this MBF discussed somewhere?
I don't consider it to be a MBF — I haven't been systematically working
my way through the archive and I've really only filed a handful of bugs;
mostly quasi-duplicates due to Sphinx stuff (which is arguably more a
QA thing than to do with violation
❦ 9 juillet 2016 15:26 CEST, Chris Lamb :
> Source: python-asyncssh
> Version: 1.5.6-1
> Severity: serious
> Justification: Policy 4.9
> User: la...@debian.org
> Usertags: network-access
>
> Dear Maintainer,
>
> Whilst python-asyncssh builds successfully on unstable/amd64, according to
> Debian
Source: python-asyncssh
Version: 1.5.6-1
Severity: serious
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access
Dear Maintainer,
Whilst python-asyncssh builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build
13 matches
Mail list logo
