> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> For everyone concerned: versions of libtool already support
Brian> this. eg. cvs version of libtool 1.4, and cvs tree for
Brian> libtool 1.3x (not sure if includes the latest release of
Brian> libtool or not, it definit
> Now I have another package baz, which I am also upstream for.
> a) I want to release baz to the whole world, not just debian, but I
> do not want to create a new package whenever a debian package change
> occurs
You could just release it to Debian, but not to sunsite. And you up
> Nicolás> Packaging it native is a perfectly valid thing to do, even
> Nicolás> better than nonnative. Why? Because the Debian packaging
> Nicolás> files can be used by anyone, not just Debian. Just as the
> Nicolás> .spec files are now included in many packages.
> But there is a tr
On Sun, Feb 04, 2001 at 11:28:54PM +0100, Bas Zoetekouw wrote:
> Package: bts
bugs.debian.org would have been the correct pseudo-package.
> Well, this seems reasonable to me. It shouldn't be too hard to put an
> option in the BTS to (optionally of course) forward _all_ bugs upstream.
You're cord
> "Jim" == Jim Lynch <[EMAIL PROTECTED]> writes:
Jim> Hi, Automatically forward bugs upstream? OK, if each upstream
Jim> agrees they want ALL the bugs reported. (already evident in
Jim> current threads to the contrary, however; maintainers know
Jim> who their upstream is, and c
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> Say, I have a native package foo. Now, foo is small,
Manoj> and for the most cases the changes I upload reflect changes
Manoj> in the source; and in the case there is only a packaging
Manoj> change, well, the
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so ->
Brian> libfoo.so.2.1
For everyone concerned: versions of libtool already support this.
eg. cvs version of libtool 1.4, and cvs tree for libtool 1.3x (not
sure if includes t
Hi,
Automatically forward bugs upstream? OK, if each upstream agrees they
want ALL the bugs reported. (already evident in current threads to the
contrary, however; maintainers know who their upstream is, and can forward.
There is mechanism to flag a bug as having been forwarded upstream. So:
what,
>>"Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes:
Henrique> Erk. Let me see if I understood your point...
Henrique> You would not oppose forbidding debian revision fields for
Henrique> native packages (binary and source), but will oppose
Henrique> forbidding debian revision fie
On 5 Feb 2001, Brian May wrote:
> Marcelo> Jason's is actually a valid question concerning this
> Marcelo> thread.
>
> Well, sorry if I misunderstood the question, but I interpreted it as
My question was retorical. I know the answer is 'because it is too lame to
become a no-op on SUS c
On Sun, 04 Feb 2001, Bas Zoetekouw wrote:
> > Well, I want us *all* to get bug reports. And when I get out the NM
> > queue, I'll want to get the bug reports for my packages. But right
> > now, a significant percentage of AbiWord bug reports are never seen by
> > the developers.
>
> Well, this
(all CC:s removed)
On Sun, 04 Feb 2001, Manoj Srivastava wrote:
> -> if yes, do as you wish. But be warned that I'll be proposing in policy
> Henrique>that *SOURCE* (not binary) native packages be forbidden
> Henrique>debian revision fields (there's a good reason for that,
> Henrique>
>>"Brendan" == Brendan O'Dea <[EMAIL PROTECTED]> writes:
Brendan> On Mon, Jan 29, 2001 at 01:10:54PM -0600, Manoj Srivastava wrote:
>> What is the rationale for requiring packages *not* to declare
>> a dependency on previous versions of perl? If I have a perl script
>> that depends on perl5.00
> "Marcelo" == Marcelo E Magallon <[EMAIL PROTECTED]> writes:
Marcelo> Jason's is actually a valid question concerning this
Marcelo> thread.
Well, sorry if I misunderstood the question, but I interpreted it as
"why does libltdl need libx.la instead of loading libx.so directly?"
Wel
Package: bts
Version: n/a; reported 2000/02/04
Severity: wishlist
Sam wrote (on debian-devel):
> Well, I want us *all* to get bug reports. And when I get out the NM
> queue, I'll want to get the bug reports for my packages. But right
> now, a significant percentage of AbiWord bug reports are ne
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> The you should not be surprised by my continued
Manoj> disagreement with your analysis.
I think you may not have read my later messages where I changed
that to "I agree".
Manoj> If nothing else, the change
On Feb 04, Jonathan D. Proulx wrote:
> My $0.02,
>
> All bugs should endup in DBTS, for reasons others have stated.
>
> Communication between Debian maintainers and upstream ia a Good
> Thing[tm], atleast an introduction. If the upstream maintainer really
> wants all unfiltered debian bug report
My $0.02,
All bugs should endup in DBTS, for reasons others have stated.
Communication between Debian maintainers and upstream ia a Good
Thing[tm], atleast an introduction. If the upstream maintainer really
wants all unfiltered debian bug reports the Debian maintainer's
procmail can take care of
>>"Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
Brian> I don't think that we should be in the business of telling
Brian> anyone where they should submit their bug reports. If the
Brian> user wishes to deal with the upstream developers directly,
Brian> that is his or her prerogative.
>>"Nicolás" == Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
Nicolás> Packaging it native is a perfectly valid thing to do, even
Nicolás> better than nonnative. Why? Because the Debian packaging
Nicolás> files can be used by anyone, not just Debian. Just as the
Nicolás> .spec files are
>>"Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes:
-> if yes, do as you wish. But be warned that I'll be proposing in policy
Henrique>that *SOURCE* (not binary) native packages be forbidden
Henrique>debian revision fields (there's a good reason for that,
Henrique>see t
>>"Brian" == Brian May <[EMAIL PROTECTED]> writes:
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> I feel that native packages should not have a debian
Manoj> revision, but not strongly enough or with reasons to be
Manoj> able to convincingly argue that feeling be made mand
>>"Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes:
Henrique> On Sat, 03 Feb 2001, Brian May wrote:
>> So obviously 1 is not relevant but 2 still is. eg. consider a package
>> that was built against a buggy library, and the package has to be
>> rebuilt in order to fix the problem.
On Sun, 4 Feb 2001, Siggi Langauf wrote:
> > If your package isn't a native package you can still include the debian/
> > subdirectory in your upstream sources.
>
> Right.
>
> > There are only two differences compared to a native packge:
> > - The version number is 0.3.6-1 instead of 0.3.6 .
>
> A
Hi Siggi,
>> Siggi Langauf <[EMAIL PROTECTED]> writes:
> > Well, as I said the choice between native and non-native is simply
> > a choice of source distribuition formats, not of "status" (at least
> > IMHO).
>
> I don't quite get your point here...
"better" isn't an order relation for th
On Sun, 04 Feb 2001, Siggi Langauf wrote:
> So we can keep this bug closed and I can turn to the 0.3.7 and 0.4.0
> releases again?
IMHO for what it's worth, yes, this bug report should be closed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the dark
On Sun, 04 Feb 2001, Siggi Langauf wrote:
> On Sun, 4 Feb 2001, Adrian Bunk wrote:
> > consider the situation when an older version of your package is in frozen
> > and you must fix a RC bug but the release manager won't allow you to
>
> In that case, I'd have to make a second branch, anyway.
> Th
On Sun, 4 Feb 2001, Henrique M Holschuh wrote:
> Well, as I said the choice between native and non-native is simply a choice
> of source distribuition formats, not of "status" (at least IMHO).
I don't quite get your point here...
> If native works well for your package right, now... then by all
On Sun, 4 Feb 2001, Adrian Bunk wrote:
> If your package isn't a native package you can still include the debian/
> subdirectory in your upstream sources.
Right.
> There are only two differences compared to a native packge:
> - The version number is 0.3.6-1 instead of 0.3.6 .
Aha. There doesn't
On Sun, 04 Feb 2001, Nicolás Lichtmaier wrote:
> > Native is best choosen for packages which are not expected to be used
> > outside of Debian, btw. If I were xine's upstream, I'd package it as
> > non-native. The non-native format is more flexible.
>
> Packaging it native is a perfectly valid
On Sun, 4 Feb 2001, Adrian Bunk wrote:
> consider the situation when an older version of your package is in frozen
> and you must fix a RC bug but the release manager won't allow you to
> upload a version that contains other changes (and the version already in
> unstable contains other changes). I
On Sun, 04 Feb 2001, Siggi Langauf wrote:
> Currently, it's very unlikely that I release a debian-only update of
> xine. There's a new upstream version every two weeks (at maximum,
> averagely every week). Even if I would make a "debian only" change a few
> hours after a normal release, there are t
On Sun, 4 Feb 2001, Nicolás Lichtmaier wrote:
> > Native is best choosen for packages which are not expected to be used
> > outside of Debian, btw. If I were xine's upstream, I'd package it as
> > non-native. The non-native format is more flexible.
>
> Packaging it native is a perfectly valid t
On Sun, 4 Feb 2001, Siggi Langauf wrote:
> Hi,
Hi Siggi,
> On Sun, 4 Feb 2001, Henrique M Holschuh wrote:
>
> > [...]
> > 1. Are you likely to do small revisions that only affect the debian/
> >subdir, and the source package is big ?
> >
> >-> if yes, choose non-native, because you'll no
On Mon, Jan 29, 2001 at 01:10:54PM -0600, Manoj Srivastava wrote:
>What is the rationale for requiring packages *not* to declare
> a dependency on previous versions of perl? If I have a perl script
> that depends on perl5.005, but fails for 5.6, why _can't_ I just say
> so in the depends?
On Sun, 4 Feb 2001, Nicolás Lichtmaier wrote:
> Packaging it native is a perfectly valid thing to do, even better than
> nonnative. Why? Because the Debian packaging files can be used by anyone,
> not just Debian. Just as the .spec files are now included in many packages.
That's a good point I
> > The idea of "if it's a bug in the software -> upstream, if it's Debian
> > packaging -> Debian BTS" it's wrong and users shouldn't be told that.
> Agreed. I don't advocate this.
> Do we really need a change of policy for this? And how do we handle
> cases where it is appropriate to encourage
Hi,
On Sun, 4 Feb 2001, Henrique M Holschuh wrote:
> [...]
> 1. Are you likely to do small revisions that only affect the debian/
>subdir, and the source package is big ?
>
>-> if yes, choose non-native, because you'll not need to reupload
> the .orig.tar.gz file, just the diff,
Nicol?s Lichtmaier <[EMAIL PROTECTED]> wrote:
> The idea of "if it's a bug in the software -> upstream, if it's Debian
> packaging -> Debian BTS" it's wrong and users shouldn't be told that.
Agreed. I don't advocate this.
Do we really need a change of policy for this? And how do we handle
case
> > No, all bugs should be reported to Debian ...
> I don't think that we should be in the business of telling anyone where
> they should submit their bug reports. If the user wishes to deal with
> the upstream developers directly, that is his or her prerogative.
Of course, but Debian has a way
On Sun, 4 Feb 2001, Nicolás Lichtmaier wrote:
> > Users of Debian packages should be encouraged to file bug reports with the
> > BTS directly unless they can be absolutely sure it is an upstream bug. How
> > many of those users have the time and expertise to read/grep thousands of
> > lines of so
[EMAIL PROTECTED] (Nicolas Lichtmaier) wrote:
> No, all bugs should be reported to Debian ...
I don't think that we should be in the business of telling anyone where
they should submit their bug reports. If the user wishes to deal with
the upstream developers directly, that is his or her preroga
> Native is best choosen for packages which are not expected to be used
> outside of Debian, btw. If I were xine's upstream, I'd package it as
> non-native. The non-native format is more flexible.
Packaging it native is a perfectly valid thing to do, even better than
nonnative. Why? Because the
> Users of Debian packages should be encouraged to file bug reports with the
> BTS directly unless they can be absolutely sure it is an upstream bug. How
> many of those users have the time and expertise to read/grep thousands of
> lines of source code and make such a decision?
No, all bugs shoul
On Sun, 04 Feb 2001, Adrian Bunk wrote:
> I have with Siggi Langauf (the maintainer of xine) a discussion in bug
> #84754 whether xine is a Debian native package or not.
We've discussed something like this in -policy recently.
Basically, here's the guidelines you should follow to decide wether yo
Hi,
I have with Siggi Langauf (the maintainer of xine) a discussion in bug
#84754 whether xine is a Debian native package or not.
The facts are:
- xine is a MPEG, VCD, DVD audio/video player for X11 that runs e.g. on
FreeBSD
- Siggi is both upstream and Debian maintainer and he include the debi
Users of Debian packages should be encouraged to file bug reports with the
BTS directly unless they can be absolutely sure it is an upstream bug. How
many of those users have the time and expertise to read/grep thousands of
lines of source code and make such a decision?
The problem is that the De
>> Brian May <[EMAIL PROTECTED]> writes:
> Jason> Does anyone know *why* libtool requires this? It strikes me
> Jason> as totally unnecessary for runtime linking on linux. Maybe
> Jason> someone should fix libltdl.
>
> Lets not get off-topic into a flame war over "why does libtoo
On Sun, Feb 04, 2001 at 01:18:31AM -0800, Chris Waters wrote:
> On Sun, Feb 04, 2001 at 02:28:09AM -0600, Sam TH wrote:
>
> > Count of AbiWord bugs in Debian BTS: 59
> > Number forwarded to AbiWord developers by maintainer: 1
>
> Hey, at least the Debian BTS is public. I have my own p
On Sun, Feb 04, 2001 at 02:28:09AM -0600, Sam TH wrote:
> Count of AbiWord bugs in Debian BTS: 59
> Number forwarded to AbiWord developers by maintainer: 1
Hey, at least the Debian BTS is public. I have my own private list of
bugs for Abiword, and it's none of your business what's on
Chris Waters <[EMAIL PROTECTED]> wrote:
> Well, I'm not sure if it's technically allowed or not, but I'm sure
> Frank would allow you to forward the reports yourself, since you, at
> least, probably know what you're doing. My point remains, however,
It's certainly technically possible since the
On Sun, Feb 04, 2001 at 12:13:54AM -0800, Seth Arnold wrote:
> Hmm. While I certainly appreciate what Chris and Herbert are saying, I
> don't think all packages are created equal in this respect. Pity for the
> poor mozilla maintainer who must forward all of my mozilla bugreports to
> mozilla's bu
On Sat, Feb 03, 2001 at 11:54:31PM -0800, Chris Waters wrote:
> On Sun, Feb 04, 2001 at 01:20:56AM -0600, Sam TH wrote:
> > On Sun, Feb 04, 2001 at 05:25:15PM +1100, Herbert Xu wrote:
>
> > > You wouldn't have to do that if your downstream maintainer were doing his
> > > job properly and forwardin
* Herbert Xu <[EMAIL PROTECTED]> [010204 00:03]:
> Yes, but my point is that if the Debian maintainer were doing his job
> properly, then at least you wouldn't have to bother about tracking the
> Debian BTS since all the relevant reports should have been forwarded to
> you.
Hmm. While I certainly
On Sun, Feb 04, 2001 at 01:20:56AM -0600, Sam TH wrote:
>
> But the problem is that we have so many downstream maintainers.
> AbiWord is distributed by every major distribution, plus it's a part
> of GNOME, and of Ximian GNOME. So that's about 10 different BTSs, and
> 10 sources of bug reports an
On Sun, Feb 04, 2001 at 01:20:56AM -0600, Sam TH wrote:
> On Sun, Feb 04, 2001 at 05:25:15PM +1100, Herbert Xu wrote:
> > You wouldn't have to do that if your downstream maintainer were doing his
> > job properly and forwarding the bugs to you.
> But the problem is that we have so many downstream
On Sun, Feb 04, 2001 at 05:25:15PM +1100, Herbert Xu wrote:
> Sam TH <[EMAIL PROTECTED]> wrote:
> >
> > Well, speaking as an upstream author, "downstream bugs", so to speak,
> > are quite annoying, in that significant effort has to be expended to
> > track and fix and close them in a dozen differen
Sam TH <[EMAIL PROTECTED]> wrote:
>
> Well, speaking as an upstream author, "downstream bugs", so to speak,
> are quite annoying, in that significant effort has to be expended to
> track and fix and close them in a dozen different bug tracking
> systems. It would be significantly more conventient
58 matches
Mail list logo
