Russ Allbery writes:
> It would be great to get this into debuild as an option, so that you
> could pass it some flag and it would do this work to figure out the
> last Debian version and include all the changelog entries to that
> point.
>
> Maybe someone (Ben, perhaps?) could open a wishlist b
Cyril Brulebois writes:
> Ben Finney (19/01/2009):
>> latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
>> | cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')
> Beware, you need to limit that to the source (in case there's a binary
> built that has the same name, and in case
Neil Williams (19/01/2009):
> It is simple to pass the -v option to dpkg-buildpackage and then dpkg
> includes all the changes since the specified -v into the .changes file
> and the bugs get closed just fine.
It is very simple to overlook/forget about passing once one is
(finally!) satisfied wit
Ben Finney (19/01/2009):
> Yes, that's exactly what I was hoping to get from my packages (and
> thought it was my responsibility to do so; I wasn't fully aware that
> the sponsor re-builds the package and uploads the result).
(Just for completeness, from a pratical point of view:)
Well, you uplo
Ben Finney (19/01/2009):
> latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
> | cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')
Beware, you need to limit that to the source (in case there's a binary
built that has the same name, and in case there are some archs out of
sync)
Paul Wise (19/01/2009):
> As a sponsor, usually I would do stuff like this:
>
> dget http://mentors.foo...-3.dsc
> apt-get source foo
> interdiff -z -p1 foo...-1.diff.gz foo...-3.diff.gz | less
Why aren't you using “debdiff foo*-{1,2}.dsc”?
Mraw,
KiBi.
signature.asc
Description: Digital s
2009/1/19 Ben Finney :
> Piotr Ożarowski writes:
>> last revision (the one you intend to upload) should not be marked as
>> UNRELEASED of course, only previous attempts should be
>
> So you're advocating to change the previous entries in the changelog?
yes
>> All I want is to be able to depend o
Piotr Ożarowski writes:
> 2009/1/19 Ben Finney :
> > However, I only upload when I release it, so at that point it's
> > not unreleased any more, and I change the suite (usually to
> > "unstable"). Why would the "UNRELEASED" suite survive to be
> > uploaded, even to mentors.debian.net?
>
> last
2009/1/19 Ben Finney :
> Piotr Ożarowski writes:
>> Since #389199 (and #386354) I strongly recommend to mark all
>> unreleased versions as UNRELEASED
>
> I do. However, I only upload when I release it, so at that point it's
> not unreleased any more, and I change the suite (usually to
> "unstable"
Neil Williams writes:
> On Mon, 19 Jan 2009 20:54:04 +1100
> Ben Finney wrote:
>
> > Neil Williams writes:
> >
> > > The maintainer doesn't have to worry about -v [for
> > > ‘dpkg-genchanges’] - the sponsor does that with the final build
> > > that actually gets uploaded to Debian.
> >
> > A
Piotr Ożarowski writes:
> Since #389199 (and #386354) I strongly recommend to mark all
> unreleased versions as UNRELEASED
I do. However, I only upload when I release it, so at that point it's
not unreleased any more, and I change the suite (usually to
“unstable”). Why would the “UNRELEASED” sui
Hello,
On Mon, Jan 19, 2009 at 12:59, Ben Finney wrote:
> Sandro Tosi writes:
>> On Mon, Jan 19, 2009 at 12:16, George Danchev wrote:
>> > My context analyzer claims [1] that what Ben wrote was more like
>> > question (though the question mark and interrogative form were
>> > missing;-), rather
Sandro Tosi writes:
> Hello,
>
> On Mon, Jan 19, 2009 at 12:16, George Danchev wrote:
> > My context analyzer claims [1] that what Ben wrote was more like
> > question (though the question mark and interrogative form were
> > missing;-), rather than a ironed rule.
>
> Well, the way he wrote (a
Since #389199 (and #386354) I strongly recommend to mark all
unreleased versions as UNRELEASED
FTR: I accept packages (changelogs) with unreleased versions *only* if
these versions are marked as UNRELEASED in distribution field (or
contain non-Debian distribution names, think: f.e. Ubuntu releases
Hello,
On Mon, Jan 19, 2009 at 12:16, George Danchev wrote:
> Quoting Sandro Tosi :
>> On Mon, Jan 19, 2009 at 02:59, Ben Finney
>> wrote:
>>>
>>> * When fixing bugs that prevented a previous release (e.g. one made to
>>> mentors.debian.net) from making it into Debian (e.g. because the
>>> spo
Quoting Sandro Tosi :
On Mon, Jan 19, 2009 at 02:59, Ben Finney wrote:
* When fixing bugs that prevented a previous release (e.g. one made to
mentors.debian.net) from making it into Debian (e.g. because the
sponsor requires further changes), recommended practice is to
increment the release
On Mon, Jan 19, 2009 at 02:59, Ben Finney wrote:
> * When fixing bugs that prevented a previous release (e.g. one made to
> mentors.debian.net) from making it into Debian (e.g. because the
> sponsor requires further changes), recommended practice is to
> increment the release number and make a
On Mon, 19 Jan 2009 20:54:04 +1100
Ben Finney wrote:
> Neil Williams writes:
>
> > The maintainer doesn't have to worry about -v [for
> > ‘dpkg-genchanges’] - the sponsor does that with the final build that
> > actually gets uploaded to Debian.
>
> Ah okay. I've never had a sponsor do that; fo
Neil Williams writes:
> The maintainer doesn't have to worry about -v [for
> ‘dpkg-genchanges’] - the sponsor does that with the final build that
> actually gets uploaded to Debian.
Ah okay. I've never had a sponsor do that; following your advice with
multiple releases between actually-gets-to-D
On Mon, Jan 19, 2009 at 06:06:20AM +, Sune Vuorela wrote:
> On 2009-01-19, Ben Finney wrote:
> > * When fixing bugs that prevented a previous release (e.g. one made to
> > mentors.debian.net) from making it into Debian (e.g. because the
> > sponsor requires further changes), recommended pr
On Mon, 19 Jan 2009 17:07:00 +1100
Ben Finney wrote:
> Russ Allbery writes:
>
> > Ben Finney writes:
> >
> > > I never invoke ‘dpkg-genchanges’ manually; that's done by
> > > ‘dpkg-buildpackage’, which in turn is usually invoked by something else
> > > (e.g. ‘pbuilder’ or ‘bzr-buildpackage’ e
On Mon, 19 Jan 2009 12:59:15 +1100
Ben Finney wrote:
> Howdy all,
>
> I see a conflict in the workflow of bug fixing and packaging. I'd like
> to know that I'm wrong, or that I'm right but there is a way to get
> around it.
>
> As I understand it, the following facts hold:
>
> * When a bug is
"Paul Wise" writes:
> On Mon, Jan 19, 2009 at 5:40 PM, Ben Finney
> wrote:
>
> >> usually you would remember because you'd debdiff and interdiff
> >> against the .deb and .diff.gz in the archive.
> >
> > How will those help me to get information about the package I'm
> > about to build *before
On Mon, Jan 19, 2009 at 5:40 PM, Ben Finney wrote:
>> usually you would remember because you'd debdiff and interdiff
>> against the .deb and .diff.gz in the archive.
>
> How will those help me to get information about the package I'm about
> to build *before* issuing the commands to build it?
As
"Paul Wise" writes:
> On Mon, Jan 19, 2009 at 5:07 PM, Ben Finney
> wrote:
>
> > Okay. So is there a normal way to have the '-v' option during a
> > run set to "include all entries newer than what's currently in
> > Debian"? Or do I have to remember to set it manually each time I
> > add a new
Ben Finney writes:
> Okay. So is there a normal way to have the ‘-v’ option during a run set
> to “include all entries newer than what's currently in Debian”? Or do
> I have to remember to set it manually each time I add a new release and
> build?
I have to look it up for my packages, but you c
On Mon, Jan 19, 2009 at 5:07 PM, Ben Finney wrote:
> Okay. So is there a normal way to have the '-v' option during a run
> set to "include all entries newer than what's currently in Debian"?
> Or do I have to remember to set it manually each time I add a new
> release and build?
Maybe add some s
Russ Allbery writes:
> Ben Finney writes:
>
> > I never invoke ‘dpkg-genchanges’ manually; that's done by
> > ‘dpkg-buildpackage’, which in turn is usually invoked by something else
> > (e.g. ‘pbuilder’ or ‘bzr-buildpackage’ etc.) Is there a normal way to
> > have ‘dpkg-genchanges’ always under
On 2009-01-19, Ben Finney wrote:
> * When fixing bugs that prevented a previous release (e.g. one made to
> mentors.debian.net) from making it into Debian (e.g. because the
> sponsor requires further changes), recommended practice is to
> increment the release number and make a new changelog
Ben Finney writes:
> I never invoke ‘dpkg-genchanges’ manually; that's done by
> ‘dpkg-buildpackage’, which in turn is usually invoked by something else
> (e.g. ‘pbuilder’ or ‘bzr-buildpackage’ etc.) Is there a normal way to
> have ‘dpkg-genchanges’ always understand “include all entries newer
>
Hello,
On Mon, 19 Jan 2009, Ben Finney wrote:
> * When packages are created by ‘dpkg-buildpackage’, the ‘*_changes’
> files by default contain only changes from the latest entry in the
> changelog.
By default, yes. However, there is the "-vmmm.nnn-qqq" option which makes the
changelog of all
Howdy all,
I see a conflict in the workflow of bug fixing and packaging. I'd like
to know that I'm wrong, or that I'm right but there is a way to get
around it.
As I understand it, the following facts hold:
* When a bug is fixed in a new release, recommended practice is to put
a “Closes: bug#N
"Daniel Leidert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
The reason, why I ask: I have 2 bugs open in a package and both only
apply to Woody, but not to Sarge, Etch or Sid. So I want to know, when
or under which circumstances I can close or "drop" them.
Considering that
Am Montag, den 31.07.2006, 11:19 -0400 schrieb Justin Pryzby:
> On Mon, Jul 31, 2006 at 04:36:24PM +0200, Daniel Leidert wrote:
> > Hello,
> >
> > Short question, because I wasn't successful to find the answer myself:
> > How are bugs treated, that are tagged as $oldstable (currently woody)?
> Sin
On Mon, Jul 31, 2006 at 04:36:24PM +0200, Daniel Leidert wrote:
> Hello,
>
> Short question, because I wasn't successful to find the answer myself:
> How are bugs treated, that are tagged as $oldstable (currently woody)?
Since version tracking is implemented [0], all the "distribution tags"
mean "
Hello,
Short question, because I wasn't successful to find the answer myself:
How are bugs treated, that are tagged as $oldstable (currently woody)?
When these bugs can be closed? Or do they have to stay open for all the
time? How do you treat such bugs?
Regards, Daniel
--
To UNSUBSCRIBE, emai
On Thu, Apr 13, 2006 at 11:02:58PM +0200, Rafael Laboissiere wrote:
> Is it acceptable to manually close a bug which is fixed in experimental
> but not yet in unstable, especially when there are no plans regarding the
> upload of the fixed version to unstable in the foreseeable future?
I think so,
Rafael Laboissiere wrote:
> Is it acceptable to manually close a bug which is fixed in experimental
> but not yet in unstable, especially when there are no plans regarding the
> upload of the fixed version to unstable in the foreseeable future?
Yes, just be sure to version your close message so th
Is it acceptable to manually close a bug which is fixed in experimental
but not yet in unstable, especially when there are no plans regarding the
upload of the fixed version to unstable in the foreseeable future?
Thanks,
--
Rafael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject o
On Sat, Oct 15, 2005 at 01:16:19PM +0200, Thomas Viehmann wrote:
> Bastian Venthur wrote:
> > I when I upload a new version of my package to debian, will the
> > *whole* changelog parsed for fixed bugs, or just the last changelog
> > entry?
> All changelog entries in the .changes. Use -vVERsion wit
Bastian Venthur wrote:
> I when I upload a new version of my package to debian, will the *whole*
> changelog parsed for fixed bugs, or just the last changelog entry?
All changelog entries in the .changes. Use -vVERsion with
dpkg-buildpackages.
Kind regards
T.
--
Thomas Viehmann, http://thomas.vi
Hi Mentors,
I when I upload a new version of my package to debian, will the *whole*
changelog parsed for fixed bugs, or just the last changelog entry?
Assume the following situation.
- foo-1.0 is in the archive
- foo-1.1 fixes bug #1, but my sponsor is currently too busy to upload
- foo-1.2 fixe
On 27 Feb 2005, at 09:39, Bartosz Fenski aka fEnIo wrote:
Also you *have to* tell it to your sponsor.
Just tell him to use `dpkg-buildpackage -rfakeroot -v1.2.3-4` or
something
like that. Please read `man dpkg-buildpackage`.
I think it's ``dpkg-buildpackage -rfakeroot -sa -v1.2.3-0''.
This would t
On Sat, Feb 26, 2005 at 08:19:21PM -0500, Justin Pryzby wrote:
> > I've packaged gaim-extendedprefs and closed the ITP bug in revision
> > 3 but my sponsors upload was not accepted by katie due to a missing
> > .orig.tar.gz. On request of my sponsor I'm making some changes to
> > the package, and I
On Sun, Feb 27, 2005 at 02:11:22AM +0100, Arjan Oosting wrote:
> Hi,
>
> I've packaged gaim-extendedprefs and closed the ITP bug in revision
> 3 but my sponsors upload was not accepted by katie due to a missing
> .orig.tar.gz. On request of my sponsor I'm making some changes to
> the package, and
I'm sorry for flooding the list, my email client kept on complaining
about errors in the TO header, so I rewrote and tried to send the
message again and again. :-(
Greetings Arjan
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Hi,
I have packages gaim-extendedprefs and close the ITP in the changelog of
revision 3. My sponsors upload of revision 3 did not get accepted due to
a missing .orig.gz, and since then I have made some changes to the
package on request of my sponsor. Now I'm wondering if I should close
the ITP in
Hi,
I've packaged gaim-extendedprefs and closed the ITP bug in revision 3
but my sponsors upload was not accepted by katie due to a
missing .orig.tar.gz. On request of my sponsor I'm making some changes
to the package, and I'm wondering if I have to close the ITP again in
the changelog for revisio
On Thu, Apr 15, 2004 at 12:43:48PM -0700, Brian Nelson wrote:
> >> This led to non-closed bugs which are fixed in fact.
> >> What now? Should I close those bugs manually, or is it correct way to
> >> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3?
> >
> > Just use the contr
Kalle Kivimaa <[EMAIL PROTECTED]> writes:
> Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
>> This led to non-closed bugs which are fixed in fact.
>> What now? Should I close those bugs manually, or is it correct way to
>> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1
On Thu, Apr 15, 2004 at 12:43:48PM -0700, Brian Nelson wrote:
> >> This led to non-closed bugs which are fixed in fact.
> >> What now? Should I close those bugs manually, or is it correct way to
> >> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3?
> >
> > Just use the contr
Kalle Kivimaa <[EMAIL PROTECTED]> writes:
> Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
>> This led to non-closed bugs which are fixed in fact.
>> What now? Should I close those bugs manually, or is it correct way to
>> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> Hello.
>
> I've got question related to closing bugs.
>
> Let's say I adopted some package, and with the new upstream version
> I should close some outstanding bugs. And I did it in 1.1-1 version.
> Then I
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> Hello.
>
> I've got question related to closing bugs.
>
> Let's say I adopted some package, and with the new upstream version
> I should close some outstanding bugs. And I did it in 1.1-1 version.
> Then I
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> This led to non-closed bugs which are fixed in fact.
> What now? Should I close those bugs manually, or is it correct way to
> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3?
Just use the control interface to BTS to cl
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> This led to non-closed bugs which are fixed in fact.
> What now? Should I close those bugs manually, or is it correct way to
> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3?
Just use the control interface to BTS to cl
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> Hello.
>
> I've got question related to closing bugs.
>
> Let's say I adopted some package, and with the new upstream version
> I should close some outstanding bugs. And I did it in 1.1-1 version.
> Then I
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> Hello.
>
> I've got question related to closing bugs.
>
> Let's say I adopted some package, and with the new upstream version
> I should close some outstanding bugs. And I did it in 1.1-1 version.
> Then I
On Wed, Apr 14, 2004 at 11:16:03AM +0200, Bartosz Fenski aka fEnIo <[EMAIL
PROTECTED]> wrote:
> This led to non-closed bugs which are fixed in fact.
> What now? Should I close those bugs manually, or is it correct way to
> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3?
>
Hello.
I've got question related to closing bugs.
Let's say I adopted some package, and with the new upstream version
I should close some outstanding bugs. And I did it in 1.1-1 version.
Then I ask previous maintainer to upload it, and he pointed me out some
other needed changes.
On Wed, Apr 14, 2004 at 11:16:03AM +0200, Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]>
wrote:
> This led to non-closed bugs which are fixed in fact.
> What now? Should I close those bugs manually, or is it correct way to
> upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3?
>
Hello.
I've got question related to closing bugs.
Let's say I adopted some package, and with the new upstream version
I should close some outstanding bugs. And I did it in 1.1-1 version.
Then I ask previous maintainer to upload it, and he pointed me out some
other needed changes.
bug
> was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to
> the latest version, 1.2.1-32. So, as the new maintainer of the package, I am
> closing the bug". Do I need to say any more?
>
> (I probably wouldn't have asked if there hadn't been so
On Thu, May 29, 2003 at 07:14:39PM -0400, Neil Roeth wrote:
> I recently adopted several packages (jade, openjade, opensp) and
> several of the open bugs were fixed by NMUs, so they have "fixed"
> tags. I think all I need to do is send an email to
> [EMAIL PROTECTED] that says, "This bug was fixed
n propagated to
the latest version, 1.2.1-32. So, as the new maintainer of the package, I am
closing the bug". Do I need to say any more?
(I probably wouldn't have asked if there hadn't been so much recent flamage on
-devel about closing bugs.)
--
Neil Roeth
--
To UNSUBSCR
bug
> was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to
> the latest version, 1.2.1-32. So, as the new maintainer of the package, I am
> closing the bug". Do I need to say any more?
>
> (I probably wouldn't have asked if there hadn't been so
On Thu, May 29, 2003 at 07:14:39PM -0400, Neil Roeth wrote:
> I recently adopted several packages (jade, openjade, opensp) and
> several of the open bugs were fixed by NMUs, so they have "fixed"
> tags. I think all I need to do is send an email to
> [EMAIL PROTECTED] that says, "This bug was fixed
n propagated to
the latest version, 1.2.1-32. So, as the new maintainer of the package, I am
closing the bug". Do I need to say any more?
(I probably wouldn't have asked if there hadn't been so much recent flamage on
-devel about closing bugs.)
--
Neil Roeth
On Fri, Apr 04, 2003 at 12:18:04PM -0600, Drew Scott Daniels wrote:
> On Fri, 4 Apr 2003, Colin Watson wrote:
> > On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> > > Would anything else be there?
> >
> > Bits and pieces of state. There are no hidden bugs, if that's what you
>
On Fri, 4 Apr 2003, Colin Watson wrote:
> On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> > On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> > > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > > inside /org/bugs.debian.org/spool.
> > Would anyt
On Fri, Apr 04, 2003 at 12:18:04PM -0600, Drew Scott Daniels wrote:
> On Fri, 4 Apr 2003, Colin Watson wrote:
> > On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> > > Would anything else be there?
> >
> > Bits and pieces of state. There are no hidden bugs, if that's what you
>
On Fri, 4 Apr 2003, Colin Watson wrote:
> On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> > On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> > > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > > inside /org/bugs.debian.org/spool.
> > Would anyt
On Fri, Apr 04, 2003 at 06:34:37PM +1000, Matthew Palmer wrote:
> On Fri, 4 Apr 2003, Colin Watson wrote:
> > Bits and pieces of state. There are no hidden bugs, if that's what you
> > mean.
>
> Oooh, the irony. I've just this minute been poking around in the archived
> bugs, and came across 2087
On Fri, 4 Apr 2003, Colin Watson wrote:
> > Would anything else be there?
>
> Bits and pieces of state. There are no hidden bugs, if that's what you
> mean.
Oooh, the irony. I've just this minute been poking around in the archived
bugs, and came across 20879.log which is chmod o-r (the only one
On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > > Where might I get a copy of the bug database? Is there any way to search
> > > the bug database
On Fri, Apr 04, 2003 at 06:34:37PM +1000, Matthew Palmer wrote:
> On Fri, 4 Apr 2003, Colin Watson wrote:
> > Bits and pieces of state. There are no hidden bugs, if that's what you
> > mean.
>
> Oooh, the irony. I've just this minute been poking around in the archived
> bugs, and came across 2087
On Fri, 4 Apr 2003, Colin Watson wrote:
> > Would anything else be there?
>
> Bits and pieces of state. There are no hidden bugs, if that's what you
> mean.
Oooh, the irony. I've just this minute been poking around in the archived
bugs, and came across 20879.log which is chmod o-r (the only one
On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > > Where might I get a copy of the bug database? Is there any way to search
> > > the bug database
On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > Where might I get a copy of the bug database? Is there any way to search
> > the bug database by text?
>
> Sorry, not yet, unless you have an account on master to poke ar
On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> Where might I get a copy of the bug database? Is there any way to search
> the bug database by text?
Sorry, not yet, unless you have an account on master to poke around
inside /org/bugs.debian.org/spool.
> I also noticed that s
On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > Where might I get a copy of the bug database? Is there any way to search
> > the bug database by text?
>
> Sorry, not yet, unless you have an account on master to poke ar
On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> Where might I get a copy of the bug database? Is there any way to search
> the bug database by text?
Sorry, not yet, unless you have an account on master to poke around
inside /org/bugs.debian.org/spool.
> I also noticed that s
Hi,
Where might I get a copy of the bug database? Is there any way to search
the bug database by text? I filed a bug (#187064 [1]) against
bugs.debian.org, but I want to know if there may be some kind of work
around. Please note that "good" search engines cannot be used due to the
robots.txt file o
Hi,
Where might I get a copy of the bug database? Is there any way to search
the bug database by text? I filed a bug (#187064 [1]) against
bugs.debian.org, but I want to know if there may be some kind of work
around. Please note that "good" search engines cannot be used due to the
robots.txt file o
On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> is there any automatic behind the (Closes: #12345) in the changelog? Is
> this parsed after upload to close bugs?
This is in the developer's reference. I encourage you to read it in its
entirety.
--
- mdz
On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> is there any automatic behind the (Closes: #12345) in the changelog? Is
> this parsed after upload to close bugs?
This is in the developer's reference. I encourage you to read it in its
entirety.
--
- mdz
--
To UNSUBSCRIBE, e
Teófilo Ruiz Suárez <[EMAIL PROTECTED]> wrote:
> El 1-abr-2003 a las 15:33:39, Frank Küster escribió:
> > Jesus Climent <[EMAIL PROTECTED]> schrieb:
> >
> > > On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> > >> Hi all,
> > >>
> > >> is there any automatic behind the (Closes: #1
Teófilo Ruiz Suárez <[EMAIL PROTECTED]> wrote:
> El 1-abr-2003 a las 15:33:39, Frank Küster escribió:
> > Jesus Climent <[EMAIL PROTECTED]> schrieb:
> >
> > > On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> > >> Hi all,
> > >>
> > >> is there any automatic behind the (Closes: #1
[EMAIL PROTECTED] (Frank Küster) wrote:
Thank you all. Indeed the link to the developers reference on
http://www.debian.org/devel/join/nm-step1
escaped my attention, and this document is all what I longed for so
long...
Bye, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalis
[EMAIL PROTECTED] (Frank Küster) wrote:
Thank you all. Indeed the link to the developers reference on
http://www.debian.org/devel/join/nm-step1
escaped my attention, and this document is all what I longed for so
long...
Bye, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalis
El 1-abr-2003 a las 15:33:39, Frank Küster escribió:
> Jesus Climent <[EMAIL PROTECTED]> schrieb:
>
> > On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> >> Hi all,
> >>
> >> is there any automatic behind the (Closes: #12345) in the changelog? Is
> >> this parsed after upload to cl
On Tue, Apr 01, 2003 at 03:33:39PM +0200, Frank K?ster wrote:
> Jesus Climent <[EMAIL PROTECTED]> schrieb:
> > On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank K?ster wrote:
> >> is there any automatic behind the (Closes: #12345) in the changelog? Is
> >> this parsed after upload to close bugs?
> >
Jesus Climent <[EMAIL PROTECTED]> schrieb:
> On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
>> Hi all,
>>
>> is there any automatic behind the (Closes: #12345) in the changelog? Is
>> this parsed after upload to close bugs?
>
> Sure it is.
So what should I read to learn about thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 01 Apr 2003 13:26, [EMAIL PROTECTED] (Frank Küster) wrote:
> Hi all,
>
> is there any automatic behind the (Closes: #12345) in the changelog?
> Is this parsed after upload to close bugs?
http://www.debian.org/doc/developers-reference/ch-pkg
On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> Hi all,
>
> is there any automatic behind the (Closes: #12345) in the changelog? Is
> this parsed after upload to close bugs?
Sure it is.
mooch
--
I say NO to WAR. Not with my silence. Not with my blessing. Say NO now
Jesus Clim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> Hi all,
>
> is there any automatic behind the (Closes: #12345) in the changelog?
Yes.
> Is this parsed after upload to close bugs?
Yes.
ciao,
- --
F: Warum heist ein Löwe eigentlich L
Frank Küster wrote:
> is there any automatic behind the (Closes: #12345) in the changelog? Is
> this parsed after upload to close bugs?
Yes. Actually it probably rather is the changes file generated with the aid of
the changelog. cf Developer's Reference 5.8.4 and 6.3 for the details.
Cheers
T.
El 1-abr-2003 a las 15:33:39, Frank Küster escribió:
> Jesus Climent <[EMAIL PROTECTED]> schrieb:
>
> > On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank Küster wrote:
> >> Hi all,
> >>
> >> is there any automatic behind the (Closes: #12345) in the changelog? Is
> >> this parsed after upload to cl
Hi all,
is there any automatic behind the (Closes: #12345) in the changelog? Is
this parsed after upload to close bugs?
TIA, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
On Tue, Apr 01, 2003 at 03:33:39PM +0200, Frank K?ster wrote:
> Jesus Climent <[EMAIL PROTECTED]> schrieb:
> > On Tue, Apr 01, 2003 at 02:26:30PM +0200, Frank K?ster wrote:
> >> is there any automatic behind the (Closes: #12345) in the changelog? Is
> >> this parsed after upload to close bugs?
> >
1 - 100 of 140 matches
Mail list logo
