Re: Bug#216492: FTBFS (unstable/all) missing build-dep

Wouter Verhelst <[EMAIL PROTECTED]> writes: >> > Buildd do build packages as root, AFAIK >> >> They don't. I don't think any of them do. > > AFAIK, all of them do. Some packages can't be built with fakeroot, but > must be built with sudo; to avoid having to build some packages twice, > we build e

Re: cdbs and Build-Depends-Indep

Colin Walters <[EMAIL PROTECTED]> writes: >> If Build-Depends-Indep were >> installed to satisfy 'build' their entire raison d'etre would be >> voided. > > The buildds[...] invoke 'dpkg-buildpackage -B'. > This all goes for dpkg-buildpackage too, of course. Fine and dandy; feel free to talk to

Re: the 'build' debian/rules target

Colin Watson <[EMAIL PROTECTED]> writes: > Please include the build target. It's useful for users as well. I agree. Perhaps a useful comparison would be 'make' and 'make install' - there's a reason most upstream sources keep and support those two things separately. -- James

Re: Bug#196367: debian-policy: clarify what to do about priority mismatches

[ I'm far too despair-ful of to properly reply to this thread, but... ] Manoj Srivastava <[EMAIL PROTECTED]> writes: > We have heard from the ftp master that [...] Err, no, you haven't. Richard answered as an ex-ftp-master. FWIW, I (as one of current ftp-master) support Colin's proposal. --

Bug#191411: [proposal] build-depends-indep should not be satisfied during clean target

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter Verhelst <[EMAIL PROTECTED]> writes: > I therefore propose the following change to section 7.6, which is a > partial rollback from #164035: > > `Build-Depends-Indep', `Build-Conflicts-Indep' >The `Build-Depends-Indep' and

Bug#191369: [PROPOSAL] encourage packagers to systematically prevent mis-linked libraries

Steve Langasek <[EMAIL PROTECTED]> writes: Seconded, but: + with dlopen(). Packagers may wish to use the gcc ^^^ + option -Wl,-z,defs when building a shared library. Couldn't this be a 'should'? -- James

Bug#178809: rules for Build-Depends-Indep satisfaction make no sense

Julian Gilbey <[EMAIL PROTECTED]> writes: > > In that case, the buildds are broken: they don't install > > Build-Depends-Indep, even though they do invoke the clean and build > > targets of debian/rules (through dpkg-buildpackage). See > > http://buildd.debian.org/fetch.php?&pkg=freesci&ver=0.3.4

Re: Question regarding policy (11.2)

Sam Hartman <[EMAIL PROTECTED]> writes: > However disks are cheap enough that it seems reasonable to ask > people doing development to go buy a big disk. It's not about disks so much as bandwidth. Disk may be cheap, but bandwidth isn't, at lesast not universally. I've also no idea who would wan

Re: Question regarding policy (11.2)

Bill Allombert <[EMAIL PROTECTED]> writes: > For the record, I *need* static libraries. Why? -- James

Re: Question regarding policy (11.2)

Josip Rodin <[EMAIL PROTECTED]> writes: > The static version of a library must be compiled without the > -fPIC option. It must be placed in the development > package, normally lib*-dev, but if its size > exceeds the size of the rest of the files in the development >

Bug#174982: [PROPOSAL]: Debian changelogs should be UTF-8 encoded

Colin Walters <[EMAIL PROTECTED]> writes: > + http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2279.html"; > name="UTF-8"> Could we please have a more, err, generic URL for the RFC? -- James

Re: [devel-ref, draft 2] homepage in description

Adam DiCarlo <[EMAIL PROTECTED]> writes: > Ok, here's my revision from suggestions. Added a screenshot link, > what the hell, it's all optional anyhow, and it's kinda a cute idea. Err, do we have to? I can see the value in a homepage URL (or at least why other people see the value in it) but a

Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I second the diff in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=39830&msg=108 - -- James -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 iEYEAREC

Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains "debug"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Walters <[EMAIL PROTECTED]> writes: > Any seconds? seconded. - -- James -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 iEYEARECAAYFAj1hVZYACgkQgD/uEic

Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains "debug"

Colin Walters <[EMAIL PROTECTED]> writes: > On Sun, 2002-08-18 at 15:45, Ian Jackson wrote: > > Please see also my comments in #113525. > > I personally have no strong opinion on this, really. Whoever wrote > the Rationale: part of this section obviously disagrees with you, > though. Yes, but it

Re: RFD: Essential packages, /, and /usr

Branden Robinson <[EMAIL PROTECTED]> writes: > On Fri, Jun 21, 2002 at 02:49:00PM +1000, Anthony Towns wrote: > > If you can't justify a change without reference to policy, then you > > shouldn't be suggesting it, > > !? > > No more wishlist bugs? Perhaps a rephrase would help? "If the _only_

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes: > >> Ben Collins <[EMAIL PROTECTED]> writes: > > > Yes, proposed updates do go into the pool. > > Interesting. Which Packages file points to them? Certainly not > stable's (at least not for a while), certainly not unstable's (not > permanen

Re: debian-policy override disparity

Julian Gilbey <[EMAIL PROTECTED]> writes: > On Thu, Jan 18, 2001 at 02:47:32PM -0500, Debian Installer wrote: > > There are disparities between your recently installed upload and the > > override file for the following file(s): > > > > debian-policy_3.2.1.2_all.deb: priority is overridden from op

Re: New field proposed, UUID

"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes: > > Good grief. This would require all non-rsync mirrors to redownload > > *every* .deb in the newly released distribution in whole, and > > would require every user to redownload every package they've > > installed if they want to upgrade from foo

Re: Bug#39299: PROPOSAL] permit/require use of bz2 for source packages

[ I'm not commenting on the policy proposal, just zip. ] Chris Waters <[EMAIL PROTECTED]> writes: > But zip is non-free -- you're opening a major can of worms here! zip and unzip are non-free, but the format is not and there are free compressors and uncompressors (minizip and miniunz from the zl

Re: pre-draft of FHS 2.1

Jason Gunthorpe <[EMAIL PROTECTED]> writes: > On Wed, 26 May 1999, Daniel Quinlan wrote: > > >/var/state is back at /var/lib, but using the /var/state > >specification. Moving the directory was unnecessary and was a > >stopping point for distributions. Tweaking the specification a >

Re: New non-us and main, and RSA

Jason Gunthorpe <[EMAIL PROTECTED]> writes: > It seems from what I have heard that we consider IDEA and RSA to be > non-free due to the patents on them in various countries and this is > why we have the gpg-rsa and gpg-idea modules in non-free. However we > also have libssl, openssl, cipe and ssle

Re: Software in main that is throughly useless without non-free software

Remco Blaakmeer <[EMAIL PROTECTED]> writes: > IIRC, the whole discussion started after an archive maintainer > rejected a new package that was supposed to go into main, for the > reason that _he_ thinks it is useful only if it talks a proprietary > network protocol for which there is no free serve

Re: Software in main that is throughly useless without non-free software

Remco Blaakmeer <[EMAIL PROTECTED]> writes: > Since the DFSG defines which packages can go into 'main' and which > can't, No it does not. Please read the DFSG. Policy defines what can and can't go in main. -- James

Re: Software in main that is throughly useless without non-free software

John Goerzen <[EMAIL PROTECTED]> writes: > James Troup <[EMAIL PROTECTED]> writes: > > > > Well there's an obvious discrepancy then, since MANY other programs in > > > the same boat are already in main, and have been for some time. > > > >

Re: Software in main that is throughly useless without non-free software

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Repeat after me, please. L I N K E R. L i b r a r y. S h a r e d > l i b r a r y (I hope I am not going too fast here). You're not going to fast, but you are being offensively condescending. > James> `Deprive users of choices'? Come agai

Re: Software in main that is throughly useless without non-free software

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Really? I think otherwise. I think your views are > fascist. Stop trying to control people, and impose your mores on > them. Control people? Who am I trying to control? I simply proposed an extension/alteration/whatever to policy. For so

Re: Software in main that is throughly useless without non-free software

John Goerzen <[EMAIL PROTECTED]> writes: > James Troup <[EMAIL PROTECTED]> writes: > > > > First, you are removing a very important distinction: You have no > > > control over what is on the other end of the connection. > > > > Eh? So what? &

Re: Software in main that is throughly useless without non-free software

Joseph Carter <[EMAIL PROTECTED]> writes: > On Mon, May 03, 1999 at 12:25:21PM -0700, Chris Waters wrote: > > > There is NOTHING on your system that is non-free which icq depends on to > > > run, is there? > > > > This is the point under contention. Does it matter whether a required > > non-free

Re: Software in main that is throughly useless without non-free software

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Hi, > >>"James" == James Troup <[EMAIL PROTECTED]> writes: > > >> Server != library. There is no linking. There is no requirement to use > >> it with a non-free server. > > James>

Re: Software in main that is throughly useless without non-free software

er <[EMAIL PROTECTED]> writes: > On Mon, May 03, 1999 at 11:48:29AM +0100, James Troup wrote: > > > And yet there are two attempts out there to write a free ICQ server. The > > > specs are published. Nobody has released one yet but so what? > > > > > &

Re: Software in main that is throughly useless without non-free software

John Goerzen <[EMAIL PROTECTED]> writes: > James Troup <[EMAIL PROTECTED]> writes: > > > > But that's not correct. The program can start, and it can run, on a > > > machine with solely free software. contrib is for things that > > > cannot eve

Re: Software in main that is throughly useless without non-free software

[ Please don't Cc replies to me on public lists ] Joseph Carter <[EMAIL PROTECTED]> writes: > On Sun, May 02, 1999 at 12:41:14PM +, Edward Betts wrote: > > > > So IRC and AOL are free clients, non-free servers with no free > > > > alternatives, > > > > > > There are free IRC servers, e.g. th

Re: Software in main that is throughly useless without non-free software

Edward Betts <[EMAIL PROTECTED]> writes: > So IRC and AOL are free clients, non-free servers with no free > alternatives, There are free IRC servers, e.g. the ircd package in main. > can we do the same with file formats? catdoc, mswordview and word2x > all read word documents but there is new fr

Re: Software in main that is throughly useless without non-free software

Joseph Carter <[EMAIL PROTECTED]> writes: > On Sat, May 01, 1999 at 06:12:11PM -0400, Branden Robinson wrote: > > We *do* care if, say, Apple comes up with some kind of streaming media > > server and patents the codec. > > This makes free implementations of that codec non-us. => Assuming they o

Re: Software in main that is throughly useless without non-free software

John Goerzen <[EMAIL PROTECTED]> writes: > James Troup <[EMAIL PROTECTED]> writes: > > > upload his netscape-base (IIRC) to main. The package (like tik) was > > undoubtedly DFSG free (Adam wrote it), but without netscape it served > > no useful purpose. I

Software in main that is throughly useless without non-free software

Hi, I've just rejected tik from Incoming[1] because it was targeted for main and as far as I can see depends on a non-free server to be useful. I've argued this before, for example when Adam wanted to upload his netscape-base (IIRC) to main. The package (like tik) was undoubtedly DFSG free (Adam

Re: Is the dependency rule distribution-wise?

Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Guy Maor wrote: > > I'm not sure that is such a good idea. That's the way it was done > > initially. > > The fact remains that currently noone seems to reading > [EMAIL PROTECTED] at the moment: I have gotten complaints > that people mail

Re: Gnome to be removed from debian?

Joey Hess <[EMAIL PROTECTED]> writes: > Ben Collins wrote: > > What we need is to not have infinite numbers of libgtk1.1.x libs in the > > distribution. Stick with libgtk1.1 and use shlibs to ensure things get > > recompiled against them. I would much rather have one lib and many > > programs that

Bug#32229: PROPOSED] libc-dev dependency in non-libc -dev packages

Joel Klecker <[EMAIL PROTECTED]> writes: > libc5-dev does provide libc-dev as well, but that package is not > allowed to be installed on glibc2-based Debian systems, and > libc5-altdev does not provide libc-dev. `not allowed' is simply not true. It's entirely possible to install libpwdb0g-dev on

Re: what needs to be policy?

Manoj Srivastava <[EMAIL PROTECTED]> writes: > > As maintainer of modutils I would find it troublesome if I have to > > go through the new-policy-process here for every change I > > make. Having to wait a while for each feature I add doesn't sound > > very helpful. > > FUD. If you are changing th

Re: egcc maintainer

Enrique Zanardi <[EMAIL PROTECTED]> writes: > AFAIK, ther's nothing in the policy against maintainer groups. Nope, the dreaded `exactly one maintainer' clause in 2.3.2 is still very much in place as of the latest policy. -- James

Re: DFSG and GPL -- source retention

Raul Miller <[EMAIL PROTECTED]> writes: > frankly, we should stop distributing GPLed code. Woo, woo, that would sure make for one hell of a distribution. Let's do it. -- James

Re: md5sums

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Trip wire does that. [ ... ] > Congratulations. You have just reinvented tripwire. more or less. I'd just like to point out, in case anyone had forgotten, that tripwire isn't free software. -- James

Re: md5sums

Joey Hess <[EMAIL PROTECTED]> writes: > I currently have the 4th and 8th slowest linux machines listed in the > BogoMips HOWTO: > >Intel 286 Tandy 0.75 Joey Hess <[EMAIL PROTECTED]> >Intel 386 PS2 2.34 Joey Hess <[EMAIL PROTECTED]> That's the 8th slowest? Wow.

Re: Bug#30036: debian-policy could include emacs policy

Adam Di Carlo <[EMAIL PROTECTED]> writes: > Look, I love the new system for maintaining Policy. I lobbied hard > for it. But this system is *barely* able to keep up with the course > of changes for the Packaging Manual and the Debian Policy. You can > try to deny this is true but it is. Bugs a

Re: Bug#29955: policy versions aren't parallel with packaging-manual

Richard Braakman <[EMAIL PROTECTED]> writes: > That said, I'm in favour of dropping the Standards-Version field > entirely. It adds no information, because it's generally not kept > up to date, and even when it says "2.5.0" it doesn't mean that > anyone checked it for compliance with the most rec

Re: Should -dev and -dbg libary packages depend on ${Source-Version}?

Ben Gertzfield <[EMAIL PROTECTED]> writes: > I've noticed that it's not policy for shared libraries' libblah-dev > and libblah-dbg packages to depend on libblah1 (=${Source-Version}) > of the main library. BTW: this isn't quite right; the source version doesn't necessarily match the version numbe

Re: It is ok to have a hardcoded Depends: libc6-dev ?

Marcus Brinkmann <[EMAIL PROTECTED]> writes: > Erhm, because the Hurd does use a different source package/version? So? So do glibc2.1 based architectures and they still use the same binary names. -- James

Re: It is ok to have a hardcoded Depends: libc6-dev ?

Santiago Vila <[EMAIL PROTECTED]> writes: > But I'm still in doubt about the need of a depends line at all. I'm not. > To compile *anything*, you will need libc6-dev anyway, Not necessarily, prior to the C-ified dependency generator, the kernel was self-contained enough (obviously using only m

Re: Should -dev and -dbg libary packages depend on ${Source-Vers

Shaleh <[EMAIL PROTECTED]> writes: > If the user has the libfoo-dev and libfoo installed, how can they > get out of sync? If you upload a new libfoo, a new libfoo-dev > should accompany it. Of course, but nothing forces the user to update them at the same time. > Just wondering if this is with

Bug#15946: PROPOSED] time stamps should be preserved

Manoj Srivastava <[EMAIL PROTECTED]> writes: > >> Maintainers are encouraged to preserve the modification times of > >> the upstream source files in a package, to the extent possible. > > James> This is pedantry, but is "to the extent possible" really the > James> best possible wording? > >

Bug#15946: PROPOSED] time stamps should be preserved

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Maintainers are encouraged to preserve the modification times of > the upstream source files in a package, to the extent possible. This is pedantry, but is "to the extent possible" really the best possible wording? It doesn't sound right to me in

Bug#17621: PROPOSED]: About versions based on dates

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Native Debian packages (i.e., packages which have been written > especially for Debian) whose version numbers include dates should > always use the `-MM-DD' format. That's a stunningly bad idea. From Chapter 5 of the Packaging ma

Re: bug #23953 ae: postinst does not check for errors

Dale Scheetz <[EMAIL PROTECTED]> writes: > The problem isn't in the postinst (I know neither of them use set > -e) but in the preinst script. Say what? update-alternatives is called in the *postinst*, and it's the *postinst* that is mentioned in the bug report as not checking for errors. If upd

Re: bug #23953 ae: postinst does not check for errors

Dale Scheetz <[EMAIL PROTECTED]> writes: > > If update-alternatives fails, the install should *not* succeed. > > And why not? The update-alternatives failure does not impact the > further correct installation of the ae package, and after the > install ae will function completely as expected when

Re: Choosing release goals for slink

Martin Mitchell <[EMAIL PROTECTED]> writes: > it seems that 3 maintainers are not enough and you'll leave Brian to > do everything. Stop lieing; I said nothing of the sort. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [E

Re: Chosing release goals for slink

Roman Hodek <[EMAIL PROTECTED]> writes: > Just uploading the stuff might result in major desaster... A > hypothectical example: dpkg uses C++, Except dpkg is written in C, only dselect uses C++. (If that was the ``hypothetical'' part of your example, excuse my pedantry.) -- James ~Yawn And Wal

Re: Chosing release goals for slink

Martin Mitchell <[EMAIL PROTECTED]> writes: > (btw severity "important-ish" means severity normal to the BTS - see > #24255) Duh; I'm well aware of that, I used it for that reason. Please stop being so damn condescending and also stop telling me what to do; I'll do what I want, not what you want

Re: Chosing release goals for slink

Martin Mitchell <[EMAIL PROTECTED]> writes: > James Troup <[EMAIL PROTECTED]> writes: > > > Martin Mitchell <[EMAIL PROTECTED]> writes: > > > > > Yes, but not all of them, and not to the extent that you could call > > > it full unattended

Re: Chosing release goals for slink

Shaleh <[EMAIL PROTECTED]> writes: > Guy this is not a slam to you or any of the people who help you. It clearly is. > That said, one of the biggest problems I see facing Debian today and > in the future is that our list of packages grows daily. You exaggerate wildly. There are for more impor

Re: Chosing release goals for slink

Martin Mitchell <[EMAIL PROTECTED]> writes: > Yes, but not all of them, and not to the extent that you could call > it full unattended (NB not unsupervised) autocompiling. Rubbish. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, ema

Re: Chosing release goals for slink

Martin Mitchell <[EMAIL PROTECTED]> writes: > > > * Developer controlled automatic archive maintenance (eg removal of > > > packages automatically after GPG signed email with list of > > > packages to delete) > > > > I think this idea, as presented here, is very bad. Even with sanity > > che

Re: Chosing release goals for slink

"Jules Bean" <[EMAIL PROTECTED]> writes: > >> * Developer controlled automatic archive maintenance (eg removal of > >> packages automatically after GPG signed email with list of > >> packages to delete) > > > > I think this idea, as presented here, is very bad. Even with sanity > > checks an

Re: Chosing release goals for slink

Shaleh <[EMAIL PROTECTED]> writes: > Not to speak for him but, I take this to mean auto creation of debs > from a central repository. An idea that has been kicked around for > a while. With new machines coming RSN we should be able to have one > for every arch supported. Well don't worry, while

Re: Chosing release goals for slink

Martin Mitchell <[EMAIL PROTECTED]> writes: > * Developer controlled automatic archive maintenance (eg removal of > packages automatically after GPG signed email with list of > packages to delete) I think this idea, as presented here, is very bad. Even with sanity checks and more thought, I'

Re: generating gpg keys

Why is this on debian-policy? It has nothing to do with policy. Hamish Moffatt <[EMAIL PROTECTED]> writes: > On generating gpg keys, how can one go about getting enough entropy > on one's own machine? Here's a reply to that question from Werner on the g10 list only today. | It is really not ea

Re: Replacing/phasing out PGP (was Re: Idea for non-free organization)

[ Replying to myself, whee ] James Troup <[EMAIL PROTECTED]> writes: > If you want to generate a GNUpg key and send it to > [EMAIL PROTECTED], it'll be added. For, hopefully obvious, security reasons please PGP sign the mail. Also gnupg is still alpha software (as the 0.3

Re: Replacing/phasing out PGP (was Re: Idea for non-free organization)

[EMAIL PROTECTED] writes: > How difficult would it be to extend our infrastructure (new maintainer > acceptance; developer-keyring; dpkg-dev) with support for gpg? The debian-keyring package (to be uploaded RSN (honest)) contains a debian-keyring.gpg. If you want to generate a GNUpg key and send

Re: Bug reports and the Maintainer feild

Jason Gunthorpe <[EMAIL PROTECTED]> writes: > specificly the part where I said Joey has installed an override so > that [EMAIL PROTECTED] always goes to the list. Well, whatever, it still strikes me as very silly. You're putting a random unrelated individual (Joey) in charge of where the mail fo

Re: Bug reports and the Maintainer feild

d packages. | Maintainer: Klee Dienes and Ian Jackson <[EMAIL PROTECTED]> | Maintainer: James Troup <[EMAIL PROTECTED]> | Maintainer: Igor Grobman and James Troup <[EMAIL PROTECTED]> | Maintainer: Enrique Zanardi <[EMAIL PROTECTED]> | Maintainer: Debian QA -- James ~Yawn A

Re: Summary[2]: dpkg and alpha/beta versioning

Rob Browning <[EMAIL PROTECTED]> writes: > Actually what we should *really* do is provide > > int debian_compare_revisions(const char *a, const char *b); > > in a shared lib Umm, libdpkg.so and versioncompare() do just that. -- James ~Yawn And Walk North~ h

Re: Proposed amendment (compiling non-free packages from source in main)

Jim Pick <[EMAIL PROTECTED]> writes: > Of course, in reality, none of the ports is building only the "main" > part of the Debian - they are also building the "contrib" and > "non-free" parts.. What reality are *you* living in? Not one I recognize. I know that several (of the tiny numbers of the

Re: Version numbers with parallel frozen and unstable releases

Fabrizio Polacco <[EMAIL PROTECTED]> writes: > There is no such need between hamm and slink, so I think that using > the usual convention for NMU (package_1-2.1 ) would be enough. Can we please not overload the NMU convention? If we do it makes it very hard to determine when the maintainer last

Re: Conflicts between developers and policy

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Well, it was gfetting frustating, what with being in the middle of > two conversations, one with Dale and James, who are of the opinion > that policy is a guideline, and not a set of rules adopted by the > project Again, please don't misrepresent my

Re: first proposal for a new maintainer policy

Manoj Srivastava <[EMAIL PROTECTED]> writes: > OK. I give. And, on the principle that if you can't beat 'em, join > 'em, I now agree with Jame Troup and Dale Scheetz and formally > declare that Policy does not govern may packages from this point on, > and shall close any policy related Bugs ASAP.

Re: first proposal for a new maintainer policy

[ Not in a huge hurry to get back into this discussion, but there are a couple of inaccuarcies here ] Christian Schwarz <[EMAIL PROTECTED]> writes: > Debian QA group: The QA group is not a replacement for a > maintainer. (I verified this by asking James Troup, who's, AFAIK,

Re: symlinks and transitive dependencies?

Branden Robinson <[EMAIL PROTECTED]> writes: > Is this okay? See the bug logs for #19562. Apparently indirect dependencies are not allowed. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: first proposal for a new maintainer policy

Christian Schwarz <[EMAIL PROTECTED]> writes: > Here is a first draft of such a `maintainer policy.' It would be > nice if people could give me feedback about it. I like this proposal. It satisfies all my concerns with the previous policy and although I wasn't enthused about the idea of a master

Re: Intent to package: debian-keyring

[ Gratuitous Cc to maintainers who already read debian-devel removed; please respect the Reply-To ] Christian Schwarz <[EMAIL PROTECTED]> writes: > > > It'll be maintained by "Igor Grobman and James Troup > > > <[EMAIL PROTECTED]>". I know this

Re: Locales and Programs parsing other's output

Christian Schwarz <[EMAIL PROTECTED]> writes: > On 11 Apr 1998, James Troup wrote: > > > Christian Schwarz <[EMAIL PROTECTED]> writes: > > > > > I don't think this is a topic which belongs to the policy > > > manual. (For example, the

Re: `Every package must have exactly one maintainer'

Christian Schwarz <[EMAIL PROTECTED]> writes: > > Questions instead go to the new-maintainer alias and one of us > > answers it depending on who isn't busy at the time. This is, I > > would have thought, obviously a better situation. > > Note, that we are talking about `package maintenance', not

Re: `Every package must have exactly one maintainer'

James Troup <[EMAIL PROTECTED]> writes: > [ ... ] pgp maintenance [ ... ] Major thinko. s/pgp/debian keyring/g -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Locales and Programs parsing other's output

Christian Schwarz <[EMAIL PROTECTED]> writes: > I don't think this is a topic which belongs to the policy > manual. (For example, the policy manual doesn't include a statement > like `dereferencing NULL pointers is evil' either.) Policy includes plenty of examples of policies which potentially re

Re: `Every package must have exactly one maintainer'

Christian Schwarz <[EMAIL PROTECTED]> writes: > 4. A unique point of communication. In case of questions WRT a > packages' `interface', it's much easier for other maintainers to > get an `authoritative' answer if you have one person to contact. You continually bring up this hideously bog

Re: General bug policy

Joost Kooij <[EMAIL PROTECTED]> writes: > On Tue, 7 Apr 1998, Ian Jackson wrote: > > > I propose the following rules for dealing with disputes over bug > > reports: > > [snip] > > > 4. Noone but the maintainer of a package (or someone acting on > > their request) should close its bug reports. >

Re: RFC: Addition of "Builder: " field to non-maintainer compiled binaries

[ Redirected to debian-policy; I neither know nor care how it got to debian-private, it does not belong there. ] Juan Cespedes <[EMAIL PROTECTED]> writes: > I've patched dpkg-buildpackage, dpkg-gencontrol and dpkg-genchanges > to use the environment variable "DPKGBUILDER" if it's set, and > gen

RFC: Addition of "Builder: " field to non-maintainer compiled binaries

sing their name, not mine) to the top of debian/control: |XBC-Builder: James Troup <[EMAIL PROTECTED]> When this is done, dpkg -I on a deb shows: |22:47:[EMAIL PROTECTED]| ~/temp $dpkg -I leave*.deb | new debian package, version 2.0. | size 6618 bytes: control archive= 476 bytes. |

Re: ldconfig or not

"David Engel" <[EMAIL PROTECTED]> writes: > This issue has come up several times but nobody has ever fixed the > Debian documentation. ldconfig should (must if the library is not > in /lib or /usr/lib) always be called in the postinst script. Only iff "$1" is configure; you do *not* want to run

Re: need input: essential packages and pre-depends

Santiago Vila <[EMAIL PROTECTED]> writes: > > That's not enough reason to make a package Essential, the policy > > manual clearly states that removing a required package can leave > > your system totally FUBAR, [...] > > ... in which case it should be probably essential also. No. That's not wha

Re: need input: essential packages and pre-depends

Santiago Vila <[EMAIL PROTECTED]> writes: > > I can't see any reason for ncurses-bin to be essential. > > Well, I can see a reason: if the console is so messed up that you > don't even see "dpkg" when you write it, and you have not clear or > reset, then you have a problem. That's not enough rea

Re: need input: essential packages and pre-depends

Santiago Vila <[EMAIL PROTECTED]> writes: > > I think that no package should (or indeed does) use `clear' or > > `reset' in its preinst or without using a dependency. > > Do you mean ncurses-bin should not be essential? I think he did, and either way I can't see any reason for ncurses-bin to be

Re: Proposal how to handle mass bug reports

Ian Jackson <[EMAIL PROTECTED]> writes: > Noone may submit many bug reports or send mail to many maintainers > without prior approval for the specific person in question to send > mail under those specific circumstances. approval from whom? -- James -- To UNSUBSCRIBE, email to [EMAIL PROTE

Re: HAMM FREEZE (removed packages)

Santiago Vila <[EMAIL PROTECTED]> writes: > Non maintainer releases do not close bugs. However, a non maintainer > release that *just* fixes a bug because a bad building environment > (buggy debstd, in this case) should probably be able to close such > bugs. What do others think about this? Just

Re: PW#5-16: Use of /usr/src

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Umm, no. The kernel-* package maintainers use kernel-package, which > produces (and has produced, in the past) the packages > kernel-{headers,source,doc,image}-. There is no interaction > required between the two sets of maintainers (libc-dev and kern

Re: Deb Policy: between 2.3.0.1 and 2.4.0.0

Craig Small <[EMAIL PROTECTED]> writes: > So, what's the difference? http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/archive/changelog> http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/related-docs/upgrading.html> -- James

Re: On essential packages and dependencies

Enrique Zanardi <[EMAIL PROTECTED]> writes: > If an Essential package depends on other packages, shouldn't those > other packages be tagged Essential as well? Certainly *not*, when the other packages are libraries. [I won't give my opinion when the other packages are not libraries on the grounds

Re: `Every package must have exactly one maintainer'

Manoj Srivastava <[EMAIL PROTECTED]> writes: > James Troup <[EMAIL PROTECTED]> writes: > > > This is IMHO a trite argument ... [...] > What *did* you mean here? s/a trite argument/incorrect/. -- James

Re: `Every package must have exactly one maintainer'

Manoj Srivastava <[EMAIL PROTECTED]> writes: > One only needs look at the bug list for one of the peioneering > multi-maintainer packages (namely; dpkg) to think that possibly when > a goup is responsible for a package, in reality no one is > responsible for it. This is IMHO a trite argument as i

Re: policy violation and bug reports. - some resolution?

Christian Schwarz <[EMAIL PROTECTED]> writes: > > - make the program setuid in the .deb file. Additionally, put this in the > > postinst: > > No, games should not be `setuid', but `setgid games' only. Uh, svgalib based games have this unfortunate habit of requiring root. (Or so I've heard) -

  1   2   >