On Sat, 3 Dec, 2005 at 17:15:58 +, Colin Watson wrote:
> yaclc provides this.
I also have bug #316385: "[process.in] allow for process.in commands
to restrict themselves to a specific package (like service.in)".
Presently the BTS doesn't seem to have this functionality, but it
would probably n
On Sat, Dec 03, 2005 at 02:10:05AM +0100, Simon Richter wrote:
> The problem here would be that said test requires network connectivity,
> while the rest of lintian does not.
Indeed. Adding such a test to dput seems to me a better idea. dput
already has the need of network connectivity, it can sim
On Fri, Dec 02, 2005 at 02:01:28PM -0500, Joey Hess wrote:
> A lintian-like test to see if the listed bugs match the package before
> uploading seems more useful to me. It would have prevented this
> particular problem.
yaclc provides this.
--
Colin Watson [
Hi,
Joey Hess schrieb:
> A lintian-like test to see if the listed bugs match the package before
> uploading seems more useful to me. It would have prevented this
> particular problem.
The problem here would be that said test requires network connectivity,
while the rest of lintian does not.
On Fri, Dec 02, 2005 at 02:22:41PM +0100, Simon Richter wrote:
> Matthew Palmer wrote:
>
> >Your mission, should you choose to accept it, is dig through the Perl code
> >in merkel:/org/bugs.debian.org/scripts and work out how to add this
> >functionality.
>
> You can use "package foo" as a comm
Joey Hess <[EMAIL PROTECTED]> writes:
> A lintian-like test to see if the listed bugs match the package before
> uploading seems more useful to me. It would have prevented this
> particular problem.
IMHO, is the best and easier alternative.
--
O T A V I OS A L V A D O R
A lintian-like test to see if the listed bugs match the package before
uploading seems more useful to me. It would have prevented this
particular problem.
Perhaps I am sloppy, but I often find it useful to close some bug in a
changelog that I might not necessary have taken the time or remembered
t
Thomas Viehmann wrote:
> if sys.stdin.readline()[1:] not in ['y','Y']:
For added utility I might want to improve on that.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
'What'll we drink to?' Nick asked, holding up the glass.
'Let's drink to testing,' Bill said.
'All right,'
Hi Matt,
if that would help, I'd include a (n option that allows to) check via
bts2ldap + the attached script into dput.
That'd be less intrusive than changing the behaviour of Closes:, for
better or worse.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
#!/usr/bin/python
import
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin B. McCarty wrote:
> Simon Richter wrote:
>
>
>>Matthew Palmer wrote:
>>
>>
>>>Your mission, should you choose to accept it, is dig through the Perl
>>>code in merkel:/org/bugs.debian.org/scripts and work out how to add
>>>this functionality.
On Sat, 3 Dec 2005 03:03, Kevin B. McCarty wrote:
> Simon Richter wrote:
> > Matthew Palmer wrote:
> >> Your mission, should you choose to accept it, is dig through the Perl
> >> code in merkel:/org/bugs.debian.org/scripts and work out how to add
> >> this functionality.
> >
> > You can use "pack
Simon Richter wrote:
> Matthew Palmer wrote:
>
>> Your mission, should you choose to accept it, is dig through the Perl
>> code in merkel:/org/bugs.debian.org/scripts and work out how to add
>> this functionality.
>
> You can use "package foo" as a command to control@ to tell it ignore
> every
Hi,
Matthew Palmer wrote:
Your mission, should you choose to accept it, is dig through the Perl code
in merkel:/org/bugs.debian.org/scripts and work out how to add this
functionality.
You can use "package foo" as a command to control@ to tell it ignore
everything that does not affect bugs
On Fri, Dec 02, 2005 at 10:45:31AM +1100, Matthew Palmer wrote:
>
> Your mission, should you choose to accept it, is dig through the Perl code
> in merkel:/org/bugs.debian.org/scripts and work out how to add this
> functionality.
>
> - Matt
Maybe it is a good thing that I am neither a DD (yet)
On Fri, Dec 02, 2005 at 12:53:51AM +0100, Alexander Schmehl wrote:
> * Peter Samuelson <[EMAIL PROTECTED]> [051202 00:33]:
>
> > This has been suggested before; the standard counterargument is "what
> > about closing an ITP?"
>
> Then why not make a check (source package of bug and changelog are
* Peter Samuelson <[EMAIL PROTECTED]> [051202 00:33]:
> This has been suggested before; the standard counterargument is "what
> about closing an ITP?"
Then why not make a check (source package of bug and changelog are the
same) or (bug to be closed is an ITP)?
Yours sincerely,
Alexander
--
On Thu, Dec 01, 2005 at 05:33:11PM -0600, Peter Samuelson wrote:
>
> [Roberto C. Sanchez]
> > Is there a way to not allow changelog entries to automatically close
> > bugs assigned to other packages?
>
> This has been suggested before; the standard counterargument is "what
> about closing an ITP?
On Thu, Dec 01, 2005 at 05:45:53PM -0500, Roberto C. Sanchez wrote:
> I just had a bug that I opened (#339832) closed by a changelog entry in
> a new debconf upload. This is apparently a typo, as the changelog entry
> claims that the bug it was closing was related to a Swedish translation
> update
[Roberto C. Sanchez]
> Is there a way to not allow changelog entries to automatically close
> bugs assigned to other packages?
This has been suggested before; the standard counterargument is "what
about closing an ITP?"
signature.asc
Description: Digital signature
On Thursday 01 December 2005 23:45, Roberto C. Sanchez wrote:
> Is there a way to not allow changelog entries to automatically close
> bugs assigned to other packages?
This sounds like a usefull restriction. I've seen enough cases where the
wrong bug was closed to see the benefit of this.
If the
I just had a bug that I opened (#339832) closed by a changelog entry in
a new debconf upload. This is apparently a typo, as the changelog entry
claims that the bug it was closing was related to a Swedish translation
update.
My bug was a wishlist bug against gmessage asking for it to become an
alt
21 matches
Mail list logo
