Re: Directing Debian users to use project BTSes - should we?
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 for upstream
You wouldn't have to do that if your downstream maintainer were doing his
job properly and forwarding the bugs to you.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Directing Debian users to use project BTSes - should we?
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 different bug tracking systems. It would be significantly more conventient for upstream 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 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 and patches. Fun. Not. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgphiEqfLhdwk.pgp Description: PGP signature
Re: Directing Debian users to use project BTSes - should we?
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 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 and patches. Fun. Not. *sigh* What we have here is a failure to communicate. If the bug is forwarded properly, it WILL be in your bug tracking system. So, what's the big deal? You don't have to care whether or not we also have it in ours, and if we have it in ours, it's convenient for our users (and for us). You can IGNORE OUR BTS COMPLETELY! But we STILL want to have the bug on file in our system! Among other things, we use our BTS to decide if we're ready to release a new system, and if important bugs aren't stored there, that breaks the whole release mechanism. Now, if the maintainer doesn't do his job properly, and doesn't forward the bugs to your BTS, that's another issue, and something you may want to take up with the Debian community at large. If it's a severe enough problem, we may be able to arrange to have someone more competent take over the package. But otherwise, just keep the hell out of our BTS, buddy! :-) :-) It's no different than if I, personally, started keeping my own list of bugs in your program. And if Fred down the street did the same. As long as Fred and I forward any new bugs we discover to you, you just plain don't care. Ditto for Debian's BTS. To be honest, it's probably not really any of your business whether I or Fred or Debian keeps a list of bugs. (I also don't understand the comment about that's 10 sources of bug reports and patches. Without 3rd-party BTS's like Debian's you'd have far MORE sources of reports and patches, i.e. all the individual users. Are you saying that 10 is too few???) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Directing Debian users to use project BTSes - should we?
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 and patches.
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.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Directing Debian users to use project BTSes - should we?
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 forwarding the bugs to you. 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 and patches. Fun. Not. *sigh* What we have here is a failure to communicate. If the bug is forwarded properly, it WILL be in your bug tracking system. So, what's the big deal? You don't have to care whether or not we also have it in ours, and if we have it in ours, it's convenient for our users (and for us). You can IGNORE OUR BTS COMPLETELY! But we STILL want to have the bug on file in our system! Among other things, we use our BTS to decide if we're ready to release a new system, and if important bugs aren't stored there, that breaks the whole release mechanism. Now, if the maintainer doesn't do his job properly, and doesn't forward the bugs to your BTS, that's another issue, and something you may want to take up with the Debian community at large. If it's a severe enough problem, we may be able to arrange to have someone more competent take over the package. But otherwise, just keep the hell out of our BTS, buddy! :-) :-) It's no different than if I, personally, started keeping my own list of bugs in your program. And if Fred down the street did the same. As long as Fred and I forward any new bugs we discover to you, you just plain don't care. Ditto for Debian's BTS. To be honest, it's probably not really any of your business whether I or Fred or Debian keeps a list of bugs. (I also don't understand the comment about that's 10 sources of bug reports and patches. Without 3rd-party BTS's like Debian's you'd have far MORE sources of reports and patches, i.e. all the individual users. Are you saying that 10 is too few???) Count of AbiWord bugs in Debian BTS: 59 Number forwarded to AbiWord developers by maintainer: 1 Both the GNOME and Ximian BTSs are down at the moment, but the last time I checked, there were about 100 in the GNOME one, and about 50 in the Ximian one. Number forwarded to AbiWord developers: 0 Bugs in RedHat Bugzilla: 4 Number forwarded to AbiWord developers: 0 So, while Debian is doing better than average here, that isn't saying much. So, I wouldn't be advocating change if I thought the current system had a chance in hell of working. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpOshris3xuY.pgp Description: PGP signature
Re: Directing Debian users to use project BTSes - should we?
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 bug tracking system 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, that we want to have bugs (especially important bugs) in our BTS, even if they are forwarded to someone else. And it's really nobody's business whether or not we (or I, for that matter) keep lists of bugs, as long as we do forward the ones that should be forwarded. (And Frank knew, or should have known, that the job was dangerous when he took it! :-) IMHO, $0.02, etc. (By now, someone out there ought to have at least a dollar's worth of my opinions... anyone want to send that dollar to me? :) With all the inflation in the world, it's nice that the price of opinions has remained steady for so long. :-) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Directing Debian users to use project BTSes - should we?
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 Debian BTS is a totally
open system.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Directing Debian users to use project BTSes - should we?
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 it! :-) Seriously, you should complain to the maintainer. But the fact remains that we need to have the bugs in our BTS for our own purposes. Anyway, I only see twenty bugs against abiword, *two* of which have been forwarded, at least three have to do with the Debian packaging, and four are wishlist. I also see five closed bugs. I see two bugs against abiword-common, both Debian-specific, two against abiword-expat, one of which is Debian-specific, and one against abiword-xml. That doesn't even come close to adding up to 59, even if I grant all the Debian-specific ones *and* the closed ones. Where are you looking? Also, at a rough estimate, at least five of the real bugs against abiword in our BTS are the same issue: bad non-iso8859-1 handling. So, I wouldn't be advocating change if I thought the current system had a chance in hell of working. Have you tried? Have you asked? Have you yelled and screamed? We got flamed left, right, blued and tattooed not too long ago by the xemacs folks for exactly the *opposite* problem not too long ago. Apparently we can't win no matter what we do. Well, I'm sorry, but we have a QA process too, y'know, and it's subverted by not getting bug reports just as badly as yours is. Bottom line is that Debian package maintainers are *supposed* to forward bug reports. I know that I do. If someone isn't then he isn't doing his job, and he should be chastised, and if he persists, then maybe he shouldn't be maintaining so many packages (or something). But nothing's perfect -- heck, some days, I discover bugs in random programs, and then forget to report them to *anyone*. Claiming that our whole system is broken, just because it's not perfect is unreasonable, even if you have been suffering more than your share of our imperfections recently. Let's try to work this out like grownups, ok? cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Directing Debian users to use project BTSes - should we?
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 private list of bugs for Abiword, and it's none of your business what's on it! :-) Seriously, you should complain to the maintainer. But the fact remains that we need to have the bugs in our BTS for our own purposes. Well, I wholly support having bugs in the Debian BTS. It's just that the odds of people submitting them to *both* systems is 0. And given the choice, I'd rather have them in the abiword bugzilla. Anyway, I only see twenty bugs against abiword, *two* of which have been forwarded, at least three have to do with the Debian packaging, and four are wishlist. I also see five closed bugs. I see two bugs against abiword-common, both Debian-specific, two against abiword-expat, one of which is Debian-specific, and one against abiword-xml. That doesn't even come close to adding up to 59, even if I grant all the Debian-specific ones *and* the closed ones. Where are you looking? Well, I counted the archived bugs too, since none of them were forwarded. And I didn't count any of the abiword-* bugs. And although 2 of them claim to have been forwarded, I don't think one of them ever actually got to us. Also, at a rough estimate, at least five of the real bugs against abiword in our BTS are the same issue: bad non-iso8859-1 handling. Which is also fixed upstream, in a release that's been out since Christmas. Maybe the rest of you do things differently, but all we've ever gotten from gecko is that one bug, although there are patches in the Debian source, which I have incorporated after finding them there. So you see why I don't have much faith in the system. Granted, this is better than some. Suse ships a significantly patched AbiWord, and I don't even know who the maintainer is. So, I wouldn't be advocating change if I thought the current system had a chance in hell of working. Have you tried? Have you asked? Have you yelled and screamed? Well, I try to avoid yelling and screaming whenever possible. It rarely improves things. We got flamed left, right, blued and tattooed not too long ago by the xemacs folks for exactly the *opposite* problem not too long ago. Apparently we can't win no matter what we do. Well, I'm sorry, but we have a QA process too, y'know, and it's subverted by not getting bug reports just as badly as yours is. 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. Insert plea for integrated, distributed, all-powerful BTS here. Bottom line is that Debian package maintainers are *supposed* to forward bug reports. I know that I do. If someone isn't then he isn't doing his job, and he should be chastised, and if he persists, then maybe he shouldn't be maintaining so many packages (or something). But nothing's perfect -- heck, some days, I discover bugs in random programs, and then forget to report them to *anyone*. Claiming that our whole system is broken, just because it's not perfect is unreasonable, even if you have been suffering more than your share of our imperfections recently. Well, I'm glad to hear that it works better for other people. Let's try to work this out like grownups, ok? Sounds like a plan. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpSvSnMVmgS7.pgp Description: PGP signature
Bug#83669: Shared libraries
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 libtool do it this way? please. Jason's is actually a valid question concerning this thread. -- Marcelo
Re: Directing Debian users to use project BTSes - should we?
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 Debian maintainer is often overworked slaving over a hot computer and just can't deal with the administrative chores. Someone needs to examine the incoming bug reports and direct them to the Debian maintainer, the upstream author, etc. as appropriate. Debian needs to hire administrative assistants so the quality geek time is not wasted. I think that Debian has more opportunity to deal with this than any commercial entity since the workers are unpaid. Just start a recruiting drive to get more people who will help with some of the non-programming chores. At the current salary rates Debian can afford to hire at least 10 times as many people as Microsoft. On Sat, 3 Feb 2001, Chris Lawrence wrote: Date: Sat, 3 Feb 2001 19:45:00 -0600 From: Chris Lawrence [EMAIL PROTECTED] To: Debian-Policy List debian-policy@lists.debian.org Subject: Directing Debian users to use project BTSes - should we? Resent-Date: Sat, 3 Feb 2001 20:45:17 -0500 Resent-From: debian-policy@lists.debian.org I just saw something like this in a control file: XXX has its own BTS at http://XXX/. If you find an upstream problem (not packaging problem!!), please use it instead of Debian BTS. I've been seeing a few of these in packages lately (sometimes in README.Debian). However, it seems like maintainers should be the front line of support for Debian users, regardless of whether it's an upstream or packaging problem. I guess if it's entirely obvious it's an upstream problem, and the end user knows how to properly report the problem, it may not be an issue (indeed, I directly reported a wishlist item in Konqueror today to the KDE folks, though I probably wouldn't have if I had to go to a lot more hassle than typing 'reportbug -b kde konqueror'). But unless the current Debian package is in sync with upstream (which it usually won't be in stable) I can see a lot of already-fixed-in-their-version bugs getting dumped on upstream developers. Anyway, I was wondering if this is something we want to discourage in policy, or if I'm just not thinking the same way as most maintainers (i.e. my premises are flawed). Chris +--+ + Paul Wade Greenbush Technologies Corporation + + mailto:[EMAIL PROTECTED] http://www.greenbush.com/ + +--+
Question about native packages
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 debian/ subdirectory in his upstream sources Our discussion is about the following part of chapter 4 of the policy: -- snip -- 4. Version numbering Every package has a version number, in its `Version' control file field. ... The three components here are: ... debian-revision This part of the version represents the version of the modifications that were made to the package to make it a Debian binary package. It is in the same format as the upstream-version and is compared in the same way. It is optional; if it isn't present then the upstream-version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian binary package, and so there is only one `debianization' of it and therefore no revision indication is required. ... -- snip -- My interpretation of the last sentence is: The software has solely been written for one purpose: being turnded into a Debian binary package. The and so there is only one `debianization' is a conclusion that only applies when the piece of software was written specifically to be turned into a Debian binary package. Siggi's interpretation is: The software has been written with all the specific things in mind and including anything necessary to turn it into a debian binary package. The and so there is only one `debianization' is an explanation and not a conclusion. Could you please clarify whether xine is a native Debian package or not? Thanks in advance, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Question about native packages
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 you should have a package be debian-native or non-native (all IMHO): 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, dsc and changes file. 2. Are you likely to do small revisions that only affect the debian/ subdir, and the source package is small ? - if yes, do as you wish. But be warned that I'll be proposing in policy that *SOURCE* (not binary) native packages be forbidden debian revision fields (there's a good reason for that, see thread in -policy). For small source files, you should use native if you don't mind increasing the upstream release number just because of a change in debian/, otherwise, go with non-native. 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. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpau68M2RszM.pgp Description: PGP signature
Re: Directing Debian users to use project BTSes - should we?
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 should be reported to Debian (with the exception of a few very actively developed - alpha/beta quality packages like mozilla). The maintainer often knows the package better than the user, and it can make a better bug report, often summarizing many user reports he has received.
Re: Question about native packages
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 Debian packaging files can be used by anyone, not just Debian. Just as the .spec files are now included in many packages.
Re: Directing Debian users to use project BTSes - should we?
[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 prerogative. ... (with the exception of a few very actively developed - alpha/beta quality packages like mozilla). True, and I would like to add a comment. I maintain some packages that come in two versions: a stable released version, and a developer's version. In the package description of the developer's version, I clearly state that *I* do not support this software. I will support the released version, but the user installs the developer's version at his own risk. (I don't have time to fix bugs in code that changes so frequently.) Therefore, I encourage users of this version to report all bugs upstream, where active development is taking place. This is more efficient, since communication doesn't get bogged down with our BTS. (And believe me, in the years I've been a developer, I've seen communication get bogged down because of forwarding DBTS reports.) IMHO, this is a case in which it is entirely appropriate to skip our BTS, and I hope that you agree. - Brian
Re: Directing Debian users to use project BTSes - should we?
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 source code and make such a decision? No, all bugs should be reported to Debian (with the exception of a few very actively developed - alpha/beta quality packages like mozilla). The maintainer often knows the package better than the user, and it can make a better bug report, often summarizing many user reports he has received. Agreed. Even if I determine the bug is upstream and provide a suggested patch, the Debian maintainer needs the information in order to take care of the Debian users. The packages go through a transition like this: unstable-testing-frozen-stable So a delay in communicating bug reports to the Debian maintainer could cause problems here. +--+ + Paul Wade Greenbush Technologies Corporation + + mailto:[EMAIL PROTECTED] http://www.greenbush.com/ + +--+
Re: Directing Debian users to use project BTSes - should we?
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 to work that involves receiving bug reports. Debian developers should encourage users to report bugs to us. 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. ... (with the exception of a few very actively developed - alpha/beta quality packages like mozilla). True, and I would like to add a comment. I maintain some packages that come in two versions: a stable released version, and a developer's version. In the package description of the developer's version, I clearly state that *I* do not support this software. I will support the released version, but the user installs the developer's version at his own risk. (I don't have time to fix bugs in code that changes so frequently.) Therefore, I encourage users of this version to report all bugs upstream, where active development is taking place. This is more efficient, since communication doesn't get bogged down with our BTS. (And believe me, in the years I've been a developer, I've seen communication get bogged down because of forwarding DBTS reports.) IMHO, this is a case in which it is entirely appropriate to skip our BTS, and I hope that you agree. Yes, I agree. But this applies in just a few cases.
Re: Directing Debian users to use project BTSes - should we?
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 cases where it is appropriate to encourage users to deal directly with the upstream developers? - Brian
Re: Question about native packages
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, dsc and changes file. 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 typically a few other changes in CVS... 2. Are you likely to do small revisions that only affect the debian/ subdir, and the source package is small ? [...] What exactly is small? xine source tarball is about 800K. It started with some 350K in November 2000... 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. I'd add one additional scenario: Native is a good option for highly unstable software. (Here, Unstable refers to update frequency, not number of crashes.) Regards, Siggi
Re: Directing Debian users to use project BTSes - should we?
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 users to deal directly with the upstream developers? It's probably a good idea, in this and other cases. To have the things we all know and agree, probably as a guideline... Here, at Debian, we think this:, as stating official positions... Well... now we need somebody who cares enough and has English writing skills to make a proposal.. (I myself lack the latter...) =)
Re: Question about native packages
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 forgot to mention: I've had several requests from non-debian people, regarding the debianization stuff. It's nice to hear something like oh, that's how the Debian people do it! Good idea! from someone who does the FreeBSD port ;-) BTW: a .spec file is inckluded in the sources as well as a SlackBuild script for building Slackware packages. Currently, maintaining all the packaging specific parts in the same CVS tree as the main source is not only most simple but also the most productive way to do it, at least IMHO... Regards, Siggi
Bug#83977: PROPOSED] include Perl Policy
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? Because such packages don't include the paths for packaged debian modules, so you can't say Depends: perl-5.005, libfoo-perl. The rationale for excluding these paths is those modules are only guaranteed to work for the current perl. Perl-only modules *may* work if they don't use features that perl-5.005 doesn't support (our for example), but binary modules most definitly won't. I've changed the must not to a should not however. 1.3. Module Path Can you give either the default location, or example locations subject to change for the module paths? [...] Done. In the 1.4. Documentation section, it says for programs with the suffix `.1', Re-worded. 3.4.1. Architecture-Independent Modules. perl-base should be essential, and thus require no dependency. [...] Done. Updated version at http://people.debian.org/~bod/perl/perl-policy.sgml, diff attached. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633 perl-policy.sgml.diff.gz Description: Binary data
Re: Question about native packages
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 not need to reupload the .orig.tar.gz file, just the diff, dsc and changes file. 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 typically a few other changes in CVS... 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). If your package is native you'll have to make a second branch of your upstream package. ... Regards, Siggi cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Question about native packages
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 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. If your package isn't a native package you can still include the debian/ subdirectory in your upstream sources. There are only two differences compared to a native packge: - The version number is 0.3.6-1 instead of 0.3.6 . - There's a separate Debian changelog besides the upstream changelog (that doesn't tell the user about FreeBSD changes when he upgrades the package as xine currently does). cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Question about native packages
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 typically a few other changes in CVS... 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). If native works well for your package right, now... then by all means go ahead and distribute it as native. Just keep in mind that should the situation change, you might want to change to non-native format to ease up on our mirrors. Debian needs to minimize mirror sync pulse, which is the main reason for the non-native source format. If it gains you nothing, you don't have to use it. 2. Are you likely to do small revisions that only affect the debian/ subdir, and the source package is small ? [...] What exactly is small? xine source tarball is about 800K. It started with some 350K in November 2000... If you have to ask, it is not small :) I'd add one additional scenario: Native is a good option for highly unstable software. (Here, Unstable refers to update frequency, not number of crashes.) Yes. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpZITP3BYujF.pgp Description: PGP signature
Re: Question about native packages
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). If your package is native you'll have to make a second branch of your upstream package. In that case, I'd have to make a second branch, anyway. The only difference is that it's not uploaded as a whole, but only as a modified .diff.gz for non-native packages... But you're right. In that case a .diff.gz could come handy. Is there any problem switching to non-native format when that happens? Regards, Siggi
Re: Question about native packages
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 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. Obviously I mean distribute the software as .tar.gz, and a debian package with the .tar.gz renamed to .orig.tar.gz + diif and dsc files). See also the comment somewhere else in this thread about branches when you need to fix something in stable. This is not an issue if it is a for-debian-only package, as you would keep that in mind and once, say, version a.b.c goes into stable, you'd release a.d.0 into unstable, so that you can continue the a.b.# branch if you need to generate stable revisions. For non-debian-only packages, that way lies madness (one stable branch due to bugs in Debian, another due to bugs in RedHat, another due to bugs in *BSD...). Non-native IS more flexible. It was designed to be more flexible. I would still package stuff I am upstream (and not debian specific) as non-native, just for that reason. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgp12XNgmNXPN.pgp Description: PGP signature
Re: Question about native packages
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 means go ahead and distribute it as native. Just keep in mind that should the situation change, you might want to change to non-native format to ease up on our mirrors. It works quite well, for now. And yes, I am considering the change to non-natife format. But that makes things a bit more complicated than they need to be and it doesn't have any real advantage. At least not yet. Debian needs to minimize mirror sync pulse, which is the main reason for the non-native source format. If it gains you nothing, you don't have to use it. That's exactly my point. [...] What exactly is small? xine source tarball is about 800K. It started with some 350K in November 2000... If you have to ask, it is not small :) Okay, but it illustrates the amount of code change... I'd add one additional scenario: Native is a good option for highly unstable software. (Here, Unstable refers to update frequency, not number of crashes.) Yes. So we can keep this bug closed and I can turn to the 0.3.7 and 0.4.0 releases again? Thanks, Siggi
Re: Question about native packages
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. The only difference is that it's not uploaded as a whole, but only as a modified .diff.gz for non-native packages... But you're right. In that case a .diff.gz could come handy. Is there any problem switching to non-native format when that happens? Well, no, there is not; it will work and nothing will complain, AFAIK. I'd not advise you to change from non-native to native, however (because we have so many broken uploads of non-native as native that someone will end up writing a script that flags non-native-native as suspicious ;-) ). Anyway, when you change from native to non-native, the first non-native upload takes as many resources as a native upload would (because there wasn't a .orig.tar.gz in there yet), so you'll only have resource gains in a second non-native upload (of the same upstream branch -- same .orig.tar.gz). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpKNnv0zguNG.pgp Description: PGP signature
Re: Question about native packages
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 darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpPBI1V7LK6L.pgp Description: PGP signature
Re: Question about native packages
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 the { native, non-native } set.
Debian needs to minimize mirror sync pulse, which is the main
reason for the non-native source format. If it gains you nothing,
you don't have to use it.
That's exactly my point.
It would be *nice* if debian/changelog listed *only* packaging changes.
It makes easier for other people to figure out if there was a packaging
mistake form one release to the next and makes it easier to fix
packaging mistakes without having to wait for a new upstream release
(or without forcing one). If this is a problem (i.e, means more work),
I guess ChangeLog is being generated from CVS log entries, which is in
general terms a good thing.
Marcelo
PS: Fix your MTA. I see 'From: Siggi Langauf [EMAIL PROTECTED]'
Re: Question about native packages
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 . Aha. There doesn't have to be a .diff.gz?? You can simply untar your xine_0.3.6.orig.tar.gz and run dpkg-buildpackage and you'll get a xine_0.3.6-1.diff.gz that is empty. - There's a separate Debian changelog besides the upstream changelog (that doesn't tell the user about FreeBSD changes when he upgrades the package as xine currently does). Aehm, and it wouldn't tell the user about new subtitle support, AC3 digital out support, the new contrast/brightness dialog, etc. Does that really make sense? Noone prevents you from writing about upstream changes in the Debian changelog, but it looks a bit funny when I see changes in the FreeBSD port [1] when upgrading my Debian package. There's something else implicated by a non-native package: It's a clear statement that Debian is different, something many non-Debian users told me they don't like about Debian... Where do non-Debian users see if the package is a native Debian package or not and where does it make a difference? Siggi cu, Adrian [1] I'm using apt-listchanges -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Native packages, broken uploads, and debian policy
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. No source needs to change, so updating the version number is (IMHO) an overkill. Henrique Well, you're right in the overkill comment, but I wonder Henrique what would be better in the long run: make it easy to Henrique detect broken packaging (everything gets dumped into the Henrique .tar.gz, which requires a full source upload in the next Henrique version or revision -- and if the maintainer doesn't Henrique notice, the next, and the next, and the next...), or keep Henrique the possibility of adding debian revisions to native Henrique packages. Or rather than complicating the packaging system, simplify it by treating these packages for which it is undesirable to upload the sources for a small change in packaging to be treated exactly like non-native packages: have a upstream version, a diff, and a debian revision. only the diff and the debian revision changes with the new upload, and we need not make any changes in the packaging tools. It also helps in releasing the native package to the rest of the world as a orig.tar.gz tarball. manoj -- Q: How do you shoot a blue elephant? A: With a blue-elephant gun. Q: How do you shoot a pink elephant? A: Twist its trunk until it turns blue, then shoot it with a blue-elephant gun. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Native packages, broken uploads, and debian policy
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 mandatory Manoj in policy. Brian I disagree. The you should not be surprised by my continued disagreement with your analysis. Brian The problem here is that the Debian version serves two tasks: Brian 1. has the package changed from the upstream version? Brian 2. has the package been rebuilt? Eh? Brian So obviously 1 is not relevant but 2 still is. eg. consider a Brian package that was built against a buggy library, and the Brian package has to be rebuilt in order to fix the problem. No Brian source needs to change, so updating the version number is Brian (IMHO) an overkill. If nothing else, the changelog needs to be modified to reflect that the package was rebuilt, and certainly conflicts need to be introduced against the bad version numbers of the buggy library. If I can deduce what you intend, you seem to be trying to separate the packaging aspect of native debian packages from the rest of the code. In this case, you should go to the full upstream-debian versioning system, and produce a debian diff; so that you do not upload the whole source for packaging changes. I disagree that there is a burning need to have a special syntax to define a case where a revision number changes with no change in the source _or_ a diff being produced; I hold that the latter is buggy, and fails to document the need for the change. I see no need to introduce a whole new syntax for packages to accomplish this; we already have a means for decoupling the packaing code from the rest of the code. Brian Then again, the current solution isn't very optimal either. As Brian changing the Debian revision number requires changing the name Brian of the source file, even though the source file has not Brian changed. You are very mistaken. Indeed, with such an assumption, the rest of your analysis is suspect, since it may be founded upon these incorrect basis. If nothing else, the changelog needs changing, so the source has indeed changed (or the diff has) manoj -- When I left you, I was but the pupil. Now, I am the master. -- Darth Vader Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Question about native packages
Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes: - if yes, do as you wish. But be warned that I'll be proposing in policy Henriquethat *SOURCE* (not binary) native packages be forbidden Henriquedebian revision fields (there's a good reason for that, Henriquesee thread in -policy). And I'll be opposing that since I do not see the reason for separating the source vs binary package as far as versioning is concerned. manoj -- Please take note: Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Question about native packages
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 now included in many packages. But there is a trade off. Doing it native; you have to upload the whole source tree even for a small change in the control file or the rules file (and the changelog, of course); this may be suboptimal were you authoring a package which is several MB in size. manoj -- Famous last words: Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Directing Debian users to use project BTSes - should we?
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. So you agree that we should not be fobbing of users to go to the upstream and don't bother us with your petty little problems? One of the services the we provide to the community is that we can filter the problem reports, and often offer solutions to simple problems, FAQ's, and not have these bother the upstream authors, If the maintainers do not have time to deal with reports on their packages, perhaps they need to lighten their load a trifle and orphan some packages? manoj -- 1. is qmail as secure as they say? Depends on what they were saying, but most likely yes. -- Seen on debian-devel Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Directing Debian users to use project BTSes - should we?
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 this. Policy? -Jon
Re: Directing Debian users to use project BTSes - should we?
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 reports the Debian maintainer's procmail can take care of this. Presumably, if the oft-requested feature to take an interest in particular bugs or packages in debbugs is implemented, all the upstream would have to do is take an interest. I don't know if there's any easy way to monitor whether the bugs list for a particular package has changed at the moment, since the canonical access method is through CGI and I don't know if stuff like Netmind plays nicely with that. Ideally, some sort of bug management tool would be nice. reportbug (more properly, the query module) should probably include something that will automate producing mails to [EMAIL PROTECTED] and forwarding bugs upstream (and also *marking* them as forwarded in the BTS); obviously, this behavior should not be the default. But something like: querybts --manage reportbug would be nice. Now to add this brainstorm to the TODO list :) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Re: Native packages, broken uploads, and debian policy
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 changelog needs to be modified to Manoj reflect that the package was rebuilt, and certainly Manoj conflicts need to be introduced against the bad version Manoj numbers of the buggy library. No. Not necessarily the case. The maintainer doesn't have any say over what libraries are used when the autobuilders compile the code. This is an autobuilder issue, and maintainers shouldn't have to do any work if the autobuilder makes the wrong choices. Why should the maintainer have to upload a new version of the code, just because the libncurses5 library on sparc is broken and only causes problems of sparc? Or, say there is a serious problem with glibc on platform X - do you expect maintainers of all packages to upload a new package with a new changelog entry just so packages will compile against the new library? Also, realize that for the above cases, the maintainer may have compiled the package for his/her favourite platform using non-buggy libraries, so that the actual uploaded code has no problems. The autobuilders can already handler this situation fine (from what I have heard) - don't change it. Manoj I see no need to introduce a whole new syntax for Manoj packages to accomplish this; we already have a means for Manoj decoupling the packaing code from the rest of the code. See my latter message - I am not disagreeing with you. -- Brian May [EMAIL PROTECTED]
Please add auto-forwarding feature to BTS (was: Directing Debian users to use project BTSes - should we?
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 never seen by the developers. 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. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
Bug#83977: PROPOSED] include Perl Policy
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.005, but fails for 5.6, why _can't_ I just say so in the depends? Brendan Because such packages don't include the paths for packaged debian Brendan modules, so you can't say Depends: perl-5.005, libfoo-perl. Sure. So I can't depend on the modules for older perl package; but surely I can do so for the older perl binary itself? I still have some perl4 scripts lying around, BTW, that do not need any libraries, but won't work on the perl5 binary. I suspect such breakage may recur with perl6. Indeed, as long as the dependence is on just the perl binary, any such dependencies should be legal. Brendan The rationale for excluding these paths is those modules are Brendan only guaranteed to work for the current perl. Perl-only Brendan modules *may* work if they don't use features that Brendan perl-5.005 doesn't support (our for example), but binary Brendan modules most definitly won't. Brendan I've changed the must not to a should not however. I think we should add a footnote with the rationale that older perl modules may not be available, and say such a dependence is not recommended. (not a reason for a bug report, but definitely deprecated practice) manoj -- The cow is nothing but a machine which makes grass fit for us people to eat. -- John McNulty Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#83669: Shared libraries
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? Well, when libltdl loads libx.la, it knows that libx.so depends on liby.so, so it can load that library too. (Also it is more consistent because some OS don't support library interdependencies) So now we start heading off topic with questions like: why can't the interdependencies be included directly in libx.so? which are answered with answers like because current versions of libtool have problems dealing with library interdependencies. So, as I said before, I don't see how any of this is relevant to the original bug report by Ian, so I didn't discuss it earlier. Then again, I now realize that *.la files conflicting is a totally separate issue, so I probably should have bought it up at a different time. -- Brian May [EMAIL PROTECTED]
native pkg versioning (was Re: Question about native packages)
(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 Henriquethat *SOURCE* (not binary) native packages be forbidden Henriquedebian revision fields (there's a good reason for that, Henriquesee thread in -policy). And I'll be opposing that since I do not see the reason for separating the source vs binary package as far as versioning is concerned. Erk. Let me see if I understood your point... You would not oppose forbidding debian revision fields for native packages (binary and source), but will oppose forbidding debian revision fields for native packages (source) and not for native packages (binary) ? I was actually thinking of a proposal that makes it clear that it is forbidden for native source packages, and says nothing (and implies nothing) at all for native binary packages (since the current policy does not say anything about both anyway). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgphiwMxGhSu7.pgp Description: PGP signature
Re: Please add auto-forwarding feature to BTS (was: Directing Debian users to use project BTSes - should we?
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 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. In the mean time, check the relevant lists in lists.debian.org, you can, with the help of an email filter, archive something close to that functionality right now. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpS7HdopLRXx.pgp Description: PGP signature
Re: Bug#83669: Shared libraries
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 conforming systems'. The relevance is that if libtool is causing a problem for IWJs proposal then the solution is to fix the hack, not hack around the hack with another more brutal hack. Jason
Re: native pkg versioning (was Re: Question about native packages)
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 fields for native packages Henrique (source) and not for native packages (binary) ? Umm. I did not understand this at all. I guess you shall have to explain the distinction between native packages (source) and native packages (binary) to me. Say, I have a native package foo. Now, foo is small, and for the most cases the changes I upload reflect changes in the source; and in the case there is only a packaging change, well, the debian diff is the same order as the whole package, so it does not make any sense to create a separate debian revision. 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 b) The package is huge, and I do not want to upload the whole source.tar.gz whenever a packaging change occurs; I create a orig,tar,gz, a diff.gz (containing the ./debian dir, for the most part), and a debian revision; just packaging changes do not cause the whole source to be uploaded, or the ``upstream'' version changed. I don't see where the source or binary package enter the picture here. What am I missing? Are you saying I have bar_1.1.tar.gz bar_1.1.dsc bar1_1-13_i386.deb ? I want to have foo_1.1.dsc foo_1.1.tar.gz foo_1.1_i386.deb bar_1.1.orig.tar.gz bar_1.1-13.dsc bar_1.1-13.diff.gz bar_1.1-13_i386.deb Are we in disagreement here? What is it that you are calling a (source) package? As I see it, bar source == bar_1.1.orig.tar.gz + bar_1.1-13.dsc + bar_1.1-13.diff.gz? foo source == foo_1.1.tar.gz + foo_1.1.dsc manoj thoroughly confused now -- Trying to break out of the Tempter's control, one's mind writhes to and fro, like a fish pulled from its watery home onto dry ground. 34 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Please add auto-forwarding feature to BTS (was: Directing Debian users to use project BTSes - should we?
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, exactly, is missing??) -Jim
Bug#83669: Shared libraries
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 the latest release of libtool or not, it definitely includes the libtool CVS version under projects/experimental, as Heimdal already uses the new system). lrwxrwxrwx1 bam users 14 Feb 5 12:36 libl4.so - libl4.so.0.0.0* lrwxrwxrwx1 bam users 14 Feb 5 12:36 libl4.so.0 - libl4.so.0.0.0* -rwxr-xr-x1 bam users 12970 Feb 5 12:36 libl4.so.0.0.0* which is exactly what was proposed here. -- Brian May [EMAIL PROTECTED]
Re: native pkg versioning (was Re: Question about native packages)
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 debian diff is the same order as the Manoj whole package, so it does not make any sense to create a Manoj separate debian revision. In case you want a diff file, then just treat the whole package as a normal non-native package. No problem. Manoj I want to have foo_1.1.dsc foo_1.1.tar.gz foo_1.1_i386.deb Manoj bar_1.1.orig.tar.gz bar_1.1-13.dsc bar_1.1-13.diff.gz Manoj bar_1.1-13_i386.deb Exactly the same as a non-native package. No one (as far as I am aware) is trying to force you to create a native package just because you happen to be the author as well as the packager. You have to be careful to keep the roles (upstream author vs maintainer) separate (eg. don't get confused and put upstream changes in the Debian diff file or vice-versa). Even if you do get this wrong, it is still easy to fix, just release a new upstream version. Some people don't want to do worry about this, so these people can use native format, and not have to worry about the extra diff file. -- Brian May [EMAIL PROTECTED]
Re: Please add auto-forwarding feature to BTS (was: Directing Debian users to use project BTSes - should we?
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 can forward. There is mechanism Jim to flag a bug as having been forwarded upstream. So: what, Jim exactly, is missing??) My only concern with this proposal is as follows: what happens if both maintainer and upstream try to fix the same bug? Wasted effort. However, if maintainers are happy to accept this risk, I have no problem with it. -- Brian May [EMAIL PROTECTED]
Re: Please add auto-forwarding feature to BTS (was: Directing Debian users to use project BTSes - should we?
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 cordially invited to prepare and submit a patch for this if it's so easy... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: Question about native packages
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 trade off. Doing it native; you have to upload the whole source tree even for a small change in the control file or the rules file (and the changelog, of course); this may be suboptimal were you authoring a package which is several MB in size. Yes, but I see that as a collateral effect, an implementation detail. The system could allow some kind of xdelta, or it could accept an URL+md5sum and download the upstream source with wget. Speaking about concepts, I find it very appropriate to have the debian directory in the normal packages.
Re: native pkg versioning (was Re: Question about native packages)
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 upload it to sunsite only when there's something relevant to the rest of the world.
Bug#83669: dynamic creation of libx.so.n
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 definitely includes the libtool CVS Brian version under projects/experimental, as Heimdal already Brian uses the new system). As such, I recommend that we change this bug title to: dynamic creation of libx.so.n As this is the next issue at hand. In order to utilise the benefits, it should be possible to install multiple versions of the library at the same time, which means that the above symlink has to be created dynamically. update-alternatives might be a good approach to use here. -- Brian May [EMAIL PROTECTED]
