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 2016-08-20 09:07 +0200, Daniel Pocock wrote:
> On 18/08/16 10:48, Holger Levsen wrote:
>> On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote:
>>> I received a notification that a bug was closed.
>>>
>>> The email that closed the bug was a spam email sent to the
>>> address (bug-numb
On 18/08/16 10:48, Holger Levsen wrote:
> On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote:
>> I received a notification that a bug was closed.
>>
>> The email that closed the bug was a spam email sent to the
>> address (bug-number)-d...@bugs.debian.org
> [...]
>> Maybe time to star
Daniel Pocock dijo [Wed, Aug 17, 2016 at 06:38:35PM +0200]:
> I was only talking about control emails (e.g. the -done address and
> control@). The requirements for opening bugs or submitting comments
> (without pseudo-headers) could remain as they are.
>
> Maybe it could insist that emails from a
On 2016-08-18 16:13:29 +0200, Patrick Matthäi wrote:
>
> Am 18.08.2016 um 15:48 schrieb Vincent Lefevre:
> > Reject mail with "X-PHP-Originating-Script:", at least for -done?
> > I quite often see this in spam not caught by the filters, and I
> > suppose that PHP scripts do not send mail to the BT
Am 18.08.2016 um 15:48 schrieb Vincent Lefevre:
> Reject mail with "X-PHP-Originating-Script:", at least for -done?
> I quite often see this in spam not caught by the filters, and I
> suppose that PHP scripts do not send mail to the BTS; well, this
> should be easy to see with the archives.
Then y
On 2016-08-17 14:47:24 -0500, Don Armstrong wrote:
> All of that said, we certainly do appreciate better anti-spam SA rules
> for the BTS, and we do already give negative scores for messages which
> have things which look like PGP signatures and/or come from an address
> which is in the whitelist.
On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote:
> I received a notification that a bug was closed.
>
> The email that closed the bug was a spam email sent to the address
> (bug-number)-d...@bugs.debian.org
[...]
> Maybe time to start requiring PGP signatures on control emails to t
Daniel Pocock writes:
> I was only talking about control emails (e.g. the -done address and
> control@). The requirements for opening bugs or submitting comments
> (without pseudo-headers) could remain as they are.
I don't believe the spammer intended to close the bug. The bug
had already been
On Wed, 17 Aug 2016, Daniel Pocock wrote:
> I received a notification that a bug was closed.
>
> The email that closed the bug was a spam email sent to the address
> (bug-number)-d...@bugs.debian.org
>
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
>
> Maybe time to start requir
On 17/08/16 18:34, Stéphane Blondon wrote:
> Hello,
>
> Le 17/08/2016 à 18:14, Daniel Pocock a écrit :
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
>>
>> Maybe time to start requiring PGP signatures on control emails to
>> the BTS?
>
> Requiring signature will increase the level
On 17/08/16 18:29, gustavo panizzo wrote:
> On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote:
>>
>>
>> I received a notification that a bug was closed.
>>
>> The email that closed the bug was a spam email sent to the
>> address (bug-number)-d...@bugs.debian.org
>>
>>
>> https:/
Hello,
Le 17/08/2016 à 18:14, Daniel Pocock a écrit :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
>
> Maybe time to start requiring PGP signatures on control emails to the BTS?
Requiring signature will increase the level to send bugs to the BTS for
external people. And spammers co
On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote:
>
>
> I received a notification that a bug was closed.
>
> The email that closed the bug was a spam email sent to the address
> (bug-number)-d...@bugs.debian.org
>
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
It w
I received a notification that a bug was closed.
The email that closed the bug was a spam email sent to the address
(bug-number)-d...@bugs.debian.org
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
Maybe time to start requiring PGP signatures on control emails to the BTS?
Dear gregor (and others off-list),
On Fri, Apr 29, 2016 at 12:17:36PM +0200, gregor herrmann wrote:
> The BTS is version-aware and knows/displays that the bug still
> affects the version in stable.
I am aware that the BTS is version-aware, but where I have got confused is I
was assuming that mail
ll
affects the version in stable.
(Closing bugs for removed packaged [with a higher version than what's
in unstable] is basically the same as closing a bug by an upload to
unstable which also doesn't fix the same bug in stable.)
Cheers,
gregor
--
.''`. Homepage https://
OpenJDK 7 just got removed from the archive (#820703) and as is normal for
such situations all its open bugs got closed. I happened to notice because
I reported one of them (#780665). However, I reported the bug against the
version in Jessie, which still exists, and is still the only version of it
Roberto C. Sánchez wrote:
> On Sat, Oct 03, 2009 at 04:54:54PM +0200, Frank Küster wrote:
>> Hi,
>>
>> assume a binary package A has been built from source package X, but a
>> new upload of source packages X and Y moves it, and it is now built from
>> Y. Now, will the changes file of Y properly
On Sat, 03 Oct 2009, Frank Küster wrote:
> assume a binary package A has been built from source package X, but
> a new upload of source packages X and Y moves it, and it is now
> built from Y. Now, will the changes file of Y properly close the bug
> in A? In other words, will the BTS be aware of th
On Sat, Oct 03, 2009 at 04:54:54PM +0200, Frank Küster wrote:
> Hi,
>
> assume a binary package A has been built from source package X, but a
> new upload of source packages X and Y moves it, and it is now built from
> Y. Now, will the changes file of Y properly close the bug in A? In
> other wo
Hi,
assume a binary package A has been built from source package X, but a
new upload of source packages X and Y moves it, and it is now built from
Y. Now, will the changes file of Y properly close the bug in A? In
other words, will the BTS be aware of the change in source package
before the chan
Hi,
Hilmar Preusse <[EMAIL PROTECTED]> wrote:
> I just noticed that tetex-src is only in sarge and etch, hence we
> can't remove it from unstable. As we (probably) can't fix it in
> stable and it is be fixed in unstable, we have to close the bug,
> right?
I'm not sure, because we have now versio
BTW: there are in bts some translations of fuse's debconf templates... may
I close these bugs with the upload which will remove templates at all or
should I close them manually with explanation that there won't be any
questions since now?
As you want. See for example
http://packages.qa.debi
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> > > AFAIK apt-listbugs only displays open bugs, if the bug is closed
>> > > then it won't get displayed.
>> >
>> > It will be displayed even when it's closed. It does have some
>> > heuristics to avoid showing irrelevant bugs.
>> >
>> >
>>
Hi,
> > > AFAIK apt-listbugs only displays open bugs, if the bug is closed
> > > then it won't get displayed.
> >
> > It will be displayed even when it's closed. It does have some
> > heuristics to avoid showing irrelevant bugs.
> >
> >
> > > Ideally apt-listbugs needs to be updated to suppor
On Sat, Nov 12, 2005 at 09:43:26AM +0900, Junichi Uekawa
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> > >> Today I did a update of the system (yes, sid and yes I know
> > >> it can be unstable but...) and the update includes grep where
> > >> no open critical bug was seen. After Boot the syste
Hi,
> >> Today I did a update of the system (yes, sid and yes I know it
> >> can be unstable but...) and the update includes grep where no
> >> open critical bug was seen. After Boot the system was
> >> completely broken as of the libpcre dependency.
> >>
> >> So please do
> "Junichi" == Junichi Uekawa <[EMAIL PROTECTED]> writes:
Junichi> Hi,
>> Today I did a update of the system (yes, sid and yes I know it
>> can be unstable but...) and the update includes grep where no
>> open critical bug was seen. After Boot the system was
>> completely b
> So please do not close bugs bevore it is available on servers. This
> break of the system musn't be.
[...]
Hello,
This is (currently) standard practice and usually[1] there is no
manual maintainer action involved.
1. Package uploaded
2. archive software processes the package, including
2
Hi,
> Today I did a update of the system (yes, sid and yes I know it can be
> unstable but...) and the update includes grep where no open critical bug
> was seen. After Boot the system was completely broken as of the libpcre
> dependency.
>
> So please do not close bugs bevore it is available on
Klaus Ethgen <[EMAIL PROTECTED]> writes:
> Today I did a update of the system (yes, sid and yes I know it can be
> unstable but...) and the update includes grep where no open critical bug
> was seen. After Boot the system was completely broken as of the libpcre
> dependency.
>
> So please do not c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today I did a update of the system (yes, sid and yes I know it can be
unstable but...) and the update includes grep where no open critical bug
was seen. After Boot the system was completely broken as of the libpcre
dependency.
So please do not close b
On Mon, Oct 17, 2005 at 03:16:01AM +0200, Henning Makholm wrote:
> If I understand correctly, after version tracking was implemented, the
> fixed-in-experimental tag has been superseded by simply closing the
> bug for the current experimental version (i.e. mailing [EMAIL PROTECTED]
> with a pseudo-
Scripsit "Jan C. Nordholz" <[EMAIL PROTECTED]>
> Now I'd like to save the maintainer some work and tag the bug
> fixed-in-experimental myself (together with a short explanatory
> message to the bug log),
If I understand correctly, after version tracking was implemented, the
fixed-in-experimental
On Mon, Oct 17, 2005 at 02:17:01AM +0200, Jeroen van Wolffelaar wrote:
> Yes, you may do so -- if in doubt, simply write an explanatory mail to
> [EMAIL PROTECTED], and let the maintainer deal with it. If you're sure
> that what you're doing is correct, there is in general no reason to not do it.
>
"Jan C. Nordholz" <[EMAIL PROTECTED]> writes:
> I'd like to ask you if it is desired (and possible at all)
> that submitters close their own bugs if they have been fixed
> without the package maintainer's noticing. The informational
> pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying
This one time, at band camp, Jan C. Nordholz said:
> Dear list,
>
> I'd like to ask you if it is desired (and possible at all)
> that submitters close their own bugs if they have been fixed
> without the package maintainer's noticing. The informational
> pages on b.d.o don't state whether [EMAIL P
On Mon, Oct 17, 2005 at 02:09:06AM +0200, Jan C. Nordholz wrote:
> Dear list,
>
> I'd like to ask you if it is desired (and possible at all)
> that submitters close their own bugs if they have been fixed
> without the package maintainer's noticing. The informational
> pages on b.d.o don't state wh
Dear list,
I'd like to ask you if it is desired (and possible at all)
that submitters close their own bugs if they have been fixed
without the package maintainer's noticing. The informational
pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying
commands from everyone, and whether or not
On Thu, Aug 25, 2005 at 12:25:08AM +0200, martin f krafft wrote:
> > Moreover I wonder if when closing via mail should I write in
> > Changelog sth like: this upload fixes bug number 1234567 in
> > testing and unstable which has been closed via mail, and add tag
> > sarge to bug that remain opened
* Steinar H. Gunderson [Thu, 25 Aug 2005 01:03:03 +0200]:
> BTW, does the BTS understand that the package might "fork"? Specifically, if
> I have a bug in a sarge package (say, 1.0) that is fixed in an upstream
> version 1.2, but is backported to sarge (because it's an RC bug), can I say
> that it
On Thu, Aug 25, 2005 at 12:49:19AM +0200, martin f krafft wrote:
>> AFAICT there is no support for a "done" command to [EMAIL PROTECTED]
>
> I meant "close":
>
> close 99 1.2
BTW, does the BTS understand that the package might "fork"? Specifically, if
I have a bug in a sarge package (say,
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>In recent announce about changes in BTS (Subject: BTS version tracking
>Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
>versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is
>now prefered way to closing
also sprach Frans Pop <[EMAIL PROTECTED]> [2005.08.25.0038 +0200]:
> > done 99 1.2
>
> AFAICT there is no support for a "done" command to [EMAIL PROTECTED]
I meant "close":
close 99 1.2
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft
Thu, 25 Aug 2005 00:25:08 +0200
martin f krafft <[EMAIL PROTECTED]> wrote:
> > In recent announce about changes in BTS (Subject: BTS version
> > tracking Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to
> > use new versioning system. I'm not sure if sending mail to
> > [EMAIL PROTECTED]
On Thursday 25 August 2005 00:25, martin f krafft wrote:
> done 99 1.2
AFAICT there is no support for a "done" command to [EMAIL PROTECTED]
pgps430gVp78z.pgp
Description: PGP signature
Em Qua, 2005-08-24 às 23:59 +0200, Grzegorz Bizon escreveu:
> In recent announce about changes in BTS (Subject: BTS version tracking
> Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
> versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is
> now prefered way to c
also sprach Grzegorz Bizon <[EMAIL PROTECTED]> [2005.08.24.2359 +0200]:
> Maintainer uploads fixed package into unstable and closes bug in
> Changelog, after few days corrected package enters testing, depending on
> urgency. Granted that reported bug wasn't so important to justify
> upload do stab
Hi there !
I was just wondering about few issues in BTS after recent changes -
how to close bugs in apropriate way.
Maintainer uploads fixed package into unstable and closes bug in
Changelog, after few days corrected package enters testing, depending on
urgency. Granted that reported bug wasn't
> Now that sarge is out (BTW, congrats to everybody!), can I close bug
> reports tagged "woody" ?
I think that you should close those reports if and only if corresponding
bugs are fixed in sarge.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [
Le Tue, 07 Jun 2005 19:51:03 +0200, Frank Lichtenheld a écrit :
> On Tue, Jun 07, 2005 at 05:14:12PM +0200, Rafael Laboissiere wrote:
>> Now that sarge is out (BTW, congrats to everybody!), can I close bug
>> reports tagged "woody" ?
>
> Depends. Certainly not security related bugs. For others it
On Tue, Jun 07, 2005 at 05:14:12PM +0200, Rafael Laboissiere wrote:
> Now that sarge is out (BTW, congrats to everybody!), can I close bug
> reports tagged "woody" ?
Depends. Certainly not security related bugs. For others it might
be usefull to keep them around to perhaps prevent others from repo
Now that sarge is out (BTW, congrats to everybody!), can I close bug
reports tagged "woody" ?
Cheers,
--
Rafael
[Please, Cc: replies to me.]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I've been perusing the bug catalogs, and I thought it might be useful
for others who want to help closing bugs, to see which maintainers
need the most help. Here's a list of the oldest bugs (also see the
list of bugs more than 2 years old at
master.debian.org/~ajt/oldbugs.html). Followi
On 14 Oct 1998, Ole J. Tetlie wrote:
> Quick question: When two bugs are merged, do I need to close both
> or will one closing close both, and send a message to both the
> submittors?
The documentation for the bug system says:
[...] When reports are merged
opening, closing, marking or unmark
Ole J. Tetlie wrote:
> Quick question: When two bugs are merged, do I need to close both
> or will one closing close both, and send a message to both the
> submittors?
You need to close both, imho.
Regards,
Joey
--
Unix is user friendly ... It's just picky about it's friends.
Quick question: When two bugs are merged, do I need to close both
or will one closing close both, and send a message to both the
submittors?
--
The only way tcsh "rocks" is when the rocks are attached to it's feet
in the deepest part of a very deep lake. (Linus Torvalds)
[EMAIL PROTEC
58 matches
Mail list logo
