Unidentified subject!
0subscribe
Unidentified subject!
0subscribe
Re: software depending on non-US (was: Re: Hey! Why does everybody love flaming so much? [was: `pure'])
Joey Hess [EMAIL PROTECTED] writes: Manoj Srivastava wrote: I think I tend to agree. Could some one please have a look at the non-US licences, and determine which should be non-US/main and which should be non-US/non-free? I understand that this is going to happen or is in the process of happening, as we move to the new non-us server. Yes. Guy
Re: Problem with dpkg-architecture
Marcus Brinkmann [EMAIL PROTECTED] writes: 1) Make -e the default. No way! -e is a horrible argument that makes makefiles break for mysterious reasons. You should just arrange for the overrides to be set on the command line. Guy
Re: Base packages
Laurent Martelli [EMAIL PROTECTED] writes: I think it would be better to implement a keyword search in dselect because anyway, some packages would belong to several directories. As archive maintainer, I agree with this. The section names are a very coarse method of dividing packages. Guy
Re: Size of Optional - policy and name for new Priority
Santiago Vila [EMAIL PROTECTED] writes: Good idea, but if we redefine standard, dselect will install a lot of new packages by default. Good point. I guess we need a new priority after all. Guy
Re: Size of Optional - policy and name for new Priority
This is a good idea, but rather than introduce a new priority, I propose that we loosen the definitions of the higher priorities. Currently we have Essential (a de-facto priority composed of those packages with the Essential flag on) Required Important Standard Optional Extra If our intent is that practically all systems install Standard and higher, do we really need four tiers there? Let's broaden important so it includes our current standard software and redefine standard as Ian suggested the new priority be defined. Guy
Re: smarter way to differ architectures needed?
Julian Gilbey [EMAIL PROTECTED] writes: I would suggest actually having both in the .changes file, then dinstall could decide whether to close bugs or change their severity to fixed based on the content of the two fields. I have handwritten patches to dinstall and the dpkg-dev scripts to handle this change, which I could type up and mail if it's wanted. This is already implemented. It differentiates by comparing the .dsc and .changes Maintainer. Guy
Re: Is the dependency rule distribution-wise?
Many years ago, the override files didn't include all packages. Ian and I changed it for a number of reasons: A common override file allows some consistency in the archive because a small group of people can set sections and priorities. It allows new packages to be checked before they are placed into the archive. Guy
Re: Is HTML compressed?
Adrian Bridgett [EMAIL PROTECTED] writes: I've got a package with _loads_ of .html files, but I can't see if they should be compressed or not. Practically every viewer and server can handle gzipped files. Where things break down is in following links. Not all viewer/servers will try foo.gz if foo is missing. dwww does implement this well, btw. Guy
Re: Is the dependency rule distribution-wise?
Wichert Akkerman [EMAIL PROTECTED] writes: I remember comments (I think from Richard Braakman) about this: at the moment the overrides-file lists info for all packages, not only overrides. He wanted to change this for potato so indeed only overrides are in there and the information in the control file will actually become useful. I'm not sure that is such a good idea. That's the way it was done initially. Guy
Re: smarter way to differ architectures needed?
Marcus Brinkmann [EMAIL PROTECTED] writes: Can you estimate the time you need to prepare this? Can I start to work out the details for a policy proposal? First estimate how many packages are involved. If it's only a handful, it's not worth it (yet). Guy
Re: smarter way to differ architectures needed?
b looks like a reasonable solution, and would not be hard to implement. Of course, as you said, if only a handful of packages are affected, then it's less work to do c. Guy
Re: Debian breaking GPL (Was: Re: Bug#32758: userv: non-maintainer upload (alpha) diffs)
Richard Braakman [EMAIL PROTECTED] writes: I've written this script, but I don't know how much code is in use that assumes that there's only one version of each source package in the archive. mkmaintainers and archivetool are two. And dinstall obviously. Mind you, I'm just out to provide this solution. Whether it gets adopted is not up to me. It will be adopted. Guy
Re: Mangling other people's code
[EMAIL PROTECTED] (Ian Jackson) writes: Does the policy list think it would be a good idea to add a piece to the policy manual asking maintainers who inherit a package and uploaders of NMU's not to change the layout, structure or style of the source code unless it is really necessary ? No for inheritors, yes for NMUs. If a package is given away, the new maintainer should be free to reorganize the package how they see fit. People who upload NMUs shouldn't be making gratuitous changes though. Guy
Re: /etc/environment (related with bug #28446)
Francesco Potorti` [EMAIL PROTECTED] writes: As you see, the file is sourced, which means that the values of the variables defined should be properly quoted. Yes, it is a bug in login that it doesn't do this. Moreover, export instructions are needed inside /etc/environment, unless one uses the set -o allexport instruction of bash or ksh, which is almost unusable as it triggers bug #23857. This bug has been fixed upstream (yay!) and I have a new version almost ready to upload. Guy
Re: Packaging Manual 4.2.14 (Distribution:)
Zed Pobre [EMAIL PROTECTED] writes: Is this segment of the packaging manual accurate? I recall being told Either is fine as far as the archive scripts are concerned. Guy
Re: Bug#17621: [PROPOSED]: About versions based on dates
Manoj Srivastava [EMAIL PROTECTED] writes: Marco What about 960501? It's shorter. Marco (This format has NO Y2K problems.) Really? When is 010501? That version would be written as 20010501. Marco was just pointing out that abbreviating 19xx as xx doesn't always cause y2k problems. Guy
Re: terminology issues: distributions, sections, subsections
Just put non-free and contrib as part of the section. bash is in the base section. xv is in the non-free/graphics section. Guy
Re: APT in slink?
Jason Gunthorpe [EMAIL PROTECTED] writes: I could stop fiddling with the GUI (again!) and work on those issues for a bit.. ?? I think that would be a good idea. apt can then be the default dpkg method in 2.1. The GUI won't be ready for 2.1 either way. Guy
Re: Call for seconds: Policy modifications
Joel Klecker [EMAIL PROTECTED] writes: [6] I see a lot of packages using arch-debian-linux though That's a violation of policy. [7] I don't understand why we use i486 for some things and i386 for others though Because of the different outputs of `dpkg --print-architecture' and `dpkg --print-gnu-build-architecture'. That should probably be cleared up in policy. Guy
Re: Comments on policy modifications
Joseph Carter [EMAIL PROTECTED] writes: Because dwww requires essentially apache, though with effort it can work with other things. It works with boa out of the box. boa is very light-weight. Guy
Bug#26650: Packaging Manual
reassign 26650 developers-reference stop Bill Mitchell [EMAIL PROTECTED] writes: I suggest that package upload procedures and maintainer procedures for creating, renaming, relocating, and removing packages be documented. Agreed, but the more appropriate place for this is the developer's reference manual which is not a part of policy, nor should it be. I am reassigning this bug. I am the one who should write this documentation anyway. Guy
Re: Nameing of selfmade CD Images
Brederlow [EMAIL PROTECTED] writes: What would a CD Image be called that contains all of main, some of contrib and non-us and some additional Packages and some non-Debian stuff (just 1 MB or so) for m68k. The CD would contain the complete Official Image and then some more. You can't call it `Official' unless you use the official images. We're not being arbitrary on this; we just don't want Debian to get a bad reputation if CDs aren't bootable, or things aren't arranged correctly, or important files are missing. Ideally, there should be some Debian person you could send your CD to who would bless it. Until there is, we have to be conservative. Contains Debian binary-m68k or something similar? That would be fine. Guy
Re: /usr/X11R6
Manoj Srivastava [EMAIL PROTECTED] writes: This proposal also does not have an ewasy way of transitioning between releases of the X WIndow system (like, release 7, or version 12. In the current method, one may have multple copies of the X window system on the machine simultaneously, keepin one the default, and allowing others to experiment with newer version at will. Also allows an easy roll back by changing 3 links. By that reasoning all X11 binaries should be placed in /usr/X11R6 so that you can have different versions of them compiled with your different versions of X. Guy
Re: Revised proposal for updating Debian Policy documents
Looks good. The only changes I suggest are: +If the issue raised is especially contentous, or is deemed to be +suitable for review by the full set of developers, then four or more +developers can call for a hold on the proposal, and move to send the +proposal to the larger developer body as a General Resolution. *Note:* +The constitution may have additional requirements for submitting a +General Resolution, for example, a minimum number of seconders, etc. Note that technical issues may not be decided on by a General Resolution. Section 3.1 seems at odd with 3.3.1 and 3.3.2. 3.3.1 deals with technical, 3.3.2 deals with non-technical, so 3.3 deals with? I think you should remove the second two paragraphs from 3.3. 3.4. Using the Bug Tracking System If we set the maintainer of the debian-policy package to the mailing list itself, then we need only mail the BTS. Guy
Re: Maybe it's time to split debian-devel-changes
Paul Slootman [EMAIL PROTECTED] writes: Here's a top 10 of K/Day for 1998 if you're curious. debian-user 276253 I hope you mean that this is 276253K/day for _all_ subscribers, e.g. No, I just forgot to divide. It's 276K/day of email written. Sorry. Guy
Re: PROPOSAL: A mechanism for updating Debian Policy documents
Manoj Srivastava [EMAIL PROTECTED] writes: Umm, how does the tech committee figure in this? I meant to say that say, some one proposes an amendment. After discussion, people are strongly divided, and it shall take 4 people to send this to the general developer body. Where does the Tech committee come in? Now I'm confused. I thought we were talking only about technical proposals? Either way the rules for who can propose, issue, etc. technical and non-technical proposals are already in the constitution. Such a four-person rule would be unconstitutional. Guy
Re: PROPOSAL: A mechanism for updating Debian Policy documents
[EMAIL PROTECTED] (Adam P. Harris) writes: I happen to find the technical vs non-technical distinction fuzzy and not particularly helpful. The proposed constitution makes the distinction. In 4.1 Together, the Developers may ... issue *nontechnical* policy documents and statements. Later in 6.1, The Technical Committee may decide on any matter of *technical* policy. (emphasis mine) Individual developers may propose policy of course, but the only way a standard resolution can affect policy is if it's being used to override a decision made by the technical committee. Guy
Re: [rms@gnu.org: Free Software Needs Free Documentation]
Manoj Srivastava [EMAIL PROTECTED] writes: However, I do not think that standards documents (and possibly other categories [personal opinions come to mind]) benefit from being modifiable. In fact, making a modifiable document a standard undermines the validity and acceptance of the standard, since one never knows what one is agreeing to. If standards can't be modified, how can they be improved? I think there is gain in allowing standards to be modified. Modified standards must be distributed with a prominent notice that this is not the original standard and that the original standard may be obtained from wherever. Other issues of concern: Translations, and re-ormatting into a a different presentation format or conversion into a different encoding (for some documents the layout and presentation maybe very important). This is tricky. If I convert your document to print on my size of paper, or if I make your ASCII document into HTML isn't that ok? Translations should be encouraged also. Maybe Translations and reformatting must be allowed with the stipulation that there is no loss of information. That might be too vague though. The problem lies with Derived works. (Would I like a derived work of the ANSI C Standard? Sounds like what MS does) Why not? If I want to propose a new keyword in ANSI C and distribute a document called Guy's modified ANSI C, shouldn't I be allowed to? Guy
Re: PROPOSAL: A mechanism for updating Debian Policy documents
Darren Benham [EMAIL PROTECTED] writes: On 08-Aug-98 Manoj Srivastava wrote: I think that with the four volunteers that we have already, all of whom are seasoned veterans, the situation seems to be under control, and we can let the selection process be as informal as it is now. More or less the way the Technical Committee comes to be when the constitution get's ratified..?? The Technical Comittee has a much more important role than the policy maintainers. The former are arbitrators and the later are secretaries. Choosing policy maintainers on a volunteer basis is fine. The technical committee is chosen in a much more formal manner. You can read details at http://www.chiark.greenend.org.uk/~ian/debian-organisation.html, section 6. Guy
Re: PROPOSAL: A mechanism for updating Debian Policy documents
Manoj Srivastava [EMAIL PROTECTED] writes: How about this: If four or more developers call for a hold on the proposal, and move to send the proposal to the larger developer body as a SRP, then, at the proposers discretion, the proposal shall be sent to the general developers body as a SRP. The constitution already allows for how developers can override the tech committee and vice-versa. Guy
Re: Maybe it's time to split debian-devel-changes
Santiago Vila [EMAIL PROTECTED] writes: In the meantime, I think we should start thinking about the splitting of debian-devel-changes, creating lists for every architecture (we have already seven). The only reason to do this is to quell bandwidth. The discarding of uninteresting architectures can always be done by the subscriber. For example, I do this with Gnus: (setq nnmail-split-fancy '(| ;; lots of stuff elided (to\\|cc\\|x-mailing-list debian-\\(devel-\\)[EMAIL PROTECTED] (| (subject source\\|i386 debian-changes) junk ) ) ;; more stuff elided so that I can just keep abreast of any packages which upload source or i386 binaries. Guy
Re: Start for a discussion about free documentation in Debian.
Marcus Brinkmann [EMAIL PROTECTED] writes: ((NOTE: this does not mean that I can print a sgml book and sell it, as printing is a conversion [read: compilation], and must be granted in the license elsewhere to be allowed. But it means that I can print the sgml source in a book and sell it, as it would just be a verbatim copy. The distinction is hopefully clear to everyone.)) Though printing an sgml book and selling it is allowed by section 2: 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. If you want to extend program to include documentation, you must extend compilation to include such conversions. I think that we should differentiate between technical and non-technical documents. We should work on a definition of technical documents, and then say that all technical documents must obey the DFSG. Non-technical documents may obey less restrictive guidelines. Guy
Re: Next Debian goals
Martin Mitchell [EMAIL PROTECTED] writes: Please provide a rationale. Do you think most developers are incapable of handling their own packages? I'm sure most are. It's still better if we archive maintainers do it as we understand the repercussions of changes and the limitations of the scripts. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Next Debian goals
Yann Dirson [EMAIL PROTECTED] writes: * Developer controlled automatic archive maintenance (eg removal of one's own packages automatically after signed email with list of packages to delete) James Troup: probably useless; needs a lot of work for minimal gain. People helping Guy should be enough. Martin Mitchell: it would still help archive maintainers. Volunteers to implement it if noone else really wants to do it. I think you can remove this one. I actually do have scripts to do the common archive operations, which I only wrote fairly recently. I don't think it's a good idea to allow developers to activate them directly. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed amendment (compiling non-free packages from source in main)
Richard Braakman [EMAIL PROTECTED] writes: Is there a way to query make for the existence of a target? make -n foo echo foo is a valid target Guy -- 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: I don't see how this conflicts with the proposed constitution. Please give me more info on that. The constitution places no limitations on the developer's authority with regard to their own work. Your version says that the maintainers must follow policy. This solution is fine with me too, but that should be documented in the policy manual too then It's a bad idea to document things in both the policy manual and the constitution. If they conflict it might not be clear to everyone which is in the right. (If the tech-ctte overrules developers too often, I expect that some developers will give up and leave. Hope that this will never happen.) I do think that the right way to resolve a disagreement between joint maintainers of a package is with the tech committee, and not by letting the head maintainer decide. The name part should be the name of the maintainer if it is an individual, or otherwise a descriptive string. I strongly disagree! It's important to know which people are maintaining a package--that's important for the project, for the maintainers, and for the users. What if half a dozen people are maintaining? What if people drop out and come in? Wouldn't a string like Foo maintainance group make more sense? In addition, this field must represent a valid email address (as defined by RFC ). No, this is not the case. See the dpkg documentation. A lot of people cut-n-paste the contents of the Maintainer field into their mail client to send mails to the maintainers. What's the problem with this requirement? See 4.2.4. Some mechanical changes may be needed in order to use the field as an email address. [EMAIL PROTECTED], These are not _packages_! Yet you can file bugs against it, it has maintainers, etc. `c c c': AFAIK, there are no other multi-maintainer packages yet. Why are we stressing so much over these multi-maintainer packages if there are so few and there will very likely remain so few? Why not just be permissive and let people maintain packages in a fashion convenient to themselves? Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy Manual 2.4.1.0 - Copyright Information
Bob Hilliard [EMAIL PROTECTED] writes: However, lintian reports an error for the incorrect address, even when followed by the correct address. Therefore, I have removed the final paragraph of the original copyright notice, leaving in its place the two paragraphs quoted above. I believe this complies with the spirit of the policy, but not with the letter of it. Is this an acceptable procedure? If not, lintian should be modified so that it doesn't call it an error to include the old address if it also finds the correct address in the document. I think this is acceptable. It seems silly to say, write to address foo... Ignore that sentence above. You should really write to address bar. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Exceptions to policy
Oops, I guess I'm from Crete. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
Manoj Srivastava [EMAIL PROTECTED] writes: I agree that there there well may be exceptions to the individual directives in the Policy; in which case I think the exceptions (when known) should be noted in the policy. Absolutely. The policy manual should use the standard RFC definitions of must, should, and may. At first I was confused by its incorrect usage of those. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
Dale Scheetz [EMAIL PROTECTED] writes: The Policy Group was begun about the same time as the QA group, and testing, among others. Outside of Ian's original writing of the Programmer's guide et al, the current policy documents were created by this Policy Group. Memory is failing you here, Dale. The policy manual was first written by Ian in summer 96. The QA group only got formed with the release of bo. I completely agree with Manoj here. The policy manual and package conformance is one of the main reasons that the distribution is as good as it is. For developer's to treat policy as a mere guideline destroy its strength, simply because chaos would ensue as each developer followed different, perhaps reasonable, policies. As I just wrote the policy manual should be rewritten so it uses standard RFC vocabulary. Until then, we should assume all policy is must, a requirement. Any exceptions should be well documented in the package and brought up here so the policy document can be changed. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Exceptions to policy
Manoj Srivastava [EMAIL PROTECTED] writes: I submit that the project has changed since you first penned policy. Yes. We're now quite large and have maintainers with very wide levels of abilities. Unfortunately we can't always rely on maintainer's making reasonable decisions. I guess we need a meta-policy to describe how to handle policy exceptions and errors. [1] Guy [1] No, there won't be a meta-meta-policy, etc.. If you find an error or desire an exception in the meta-policy, we shoot you. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Exceptions to policy
Also, the meta policy should probably set some limitations on what the policy can and cannot cover. I believe that a policy which restricts the manner in which a package can be maintained is not only wrong. It is outside the scope of policy. Guy -- 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: Every package in the distribution must have one or more maintainers at a time (see below). That's not currently true. Orphaned packages are not typically removed from the unstable distribution. Instead their maintainer is set to (orphaned) or [EMAIL PROTECTED] I prefer the current practice. Duties of a maintainer Privileges of a maintainer The proposed constitution already provides outlines these in a better fashion. Orphaned packages [first paragraph based on s2.3.2, policy manual] It seems you agree with what I wrote above. So you should strike the Every package... sentence I quoted. And now to the crux of your post. This is a much more reasonable suggestion. My only criticism is of the requirement of a head maintainer. The proposed constitution already has a method for settling technical disagreements between developers. Choosing a head maintainer purely so that we can point the finger is disingenuous. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog vs ChangeLog and policy dictates
Manoj Srivastava [EMAIL PROTECTED] writes: My proposal is to stop micromanagement and leave some things for the maintainer to decide. Hear, hear! Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
James Troup [EMAIL PROTECTED] writes: Personally I think this package could go into hamm For what it's worth, I also think it's fine to go into hamm. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
Perhaps James was unnecessarily caustic in his post. I do disagree, however, with any policy which restricts in what manner a package can be maintained by multiple people. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release file
Jason Gunthorpe [EMAIL PROTECTED] writes: Source This specifies who is providing this archive. In the case of Debian the string will read 'Debian'. Other providers may use their own string Label This carries the encompassing name of the distribution. For Debian proper this field reads 'Debian'. For derived distributions it should contain their proper name. I don't understand the difference between these two. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and Configuration files (again)
Manoj Srivastava [EMAIL PROTECTED] writes: dpkg and friends would not need to be modified to handle extrafiles anyway. No, dpkg --search should know about them. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange Dependancies
Jason Gunthorpe [EMAIL PROTECTED] writes: I got a bug report effectively saying that dpkg permits this. Till then I had thought it was invalid. only xzip and sgml-tools make use of this. According to packaging 4.1 it is invalid, Except where otherwise stated only a single line of data is allowed. But if dpkg allows it, I guess you don't have a choice. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IMPORTANT: calling ldconfig in maintainer scripts
Christian Schwarz [EMAIL PROTECTED] writes: Any package installing shared libraries in a directory that's listed in /etc/ld.so.conf has to call ldconfig in its postinst script, unless this script is called with a failed-* or abort-* argument (in which case ldconfig may _not_ be called). Change this to must call `ldconfig' in its postinst script if and only if the first argument is `configure'. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Different versions of libc6-doc
Juan Cespedes [EMAIL PROTECTED] writes: Would it be possible for `dinstall' to have an `arch: all' package and some arch-specific packages with the same name? No, it can't handle that. I guess you call it it libc6-doc-sparc ? Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#19048: cvs-buildpackage: they should use /bin/sh and not bash
I wrote this bit of policy, and Manoj's interpretation is correct. It's nice, but not required, for scripts to use /bin/sh. Manoj is being pretty reasonable here: The code is not done yet. When I deem it finished, and if it still does not use bashisms, I shall think about changing it. Guy
Re: making room
On Tue, Mar 03, 1998 at 05:15:18PM -0800, Jim wrote: Is there a way to check how much space a package is using? I looked for an option for the dpkg -l, so that the size of each package would be shown, but found nothing. `dpkg -s foo | grep Installed-Size' ? Guy
Re: propsal: all daemons should chdir / on startup
Topi Miettinen [EMAIL PROTECTED] writes:
Doesn't being in a prosess group also affect signals?
Yes, you can send signals to an entire process group.
What if attacker
forks until it gets pid==sid_of_target_which_forgot_setsid and calls
setsid() and kill(pid_of_target)? I tried reading kernel sources, but got
lost.
That will never happen for the same reason that you can't have two
processes with the same pid.
open(/dev/null, O_RDWR);
open(/dev/null, O_RDWR);
open(/dev/null, O_RDWR);
for fake std{in,out,err}
Presumably the daemon isn't using stdin, stdout, and stderr, so you
don't need to do this. And you're not guaranteed to get the lowest
fd, even though you probably will. You should use dup/dup2 to get
specific fds.
Guy
Re: policy violation and bug reports. - some resolution?
Santiago Vila [EMAIL PROTECTED] writes: I said (IMHO) it was an error not to *ask* the user about creating a new file or leave the file in its inexisting state. It does ask the user about it if the upstream file changes though. Guy
Re: propsal: all daemons should chdir / on startup
Topi Miettinen [EMAIL PROTECTED] writes: At least atd, tcplogd, icmplogd and xfs don't do setsid(). How about adding some coding advice in Policy, something like your sentence? I don't think it's the policy document's job to teach people how to do Unix system programming. Lack of an setsid() doesn't necessarily imply that there's a bug. There are other, more complicated, ways to make sure that you don't have a controlling terminal, but unless you care about ancient Unixes I wouldn't worry about them. Startup code for a daemon would usually look something like (naturally you would have to add error checking): if (fork() == 0) exit(0); setsid(); chdir(/); umask(0); for (i=0; isysconf(_SC_OPEN_MAX); i++) close(i); Guy
Re: Clarification of Policy and Packaging manuals requested
Joey Hess [EMAIL PROTECTED] writes: Zed Pobre wrote: Shar-utils. Or perl doing uuencode. This leaves you with a huge postinst file (probably 2x the size of the actual file it generates), sitting in /var/lib/dpkg/info/. IMHO, worse than just installing a copy of the file into /usr/lib/ gzip + uuencode. Guy
Re: propsal: all daemons should chdir / on startup
Joey Hess [EMAIL PROTECTED] writes: I've noticed what seems to be a common problem lately: daemons that do not chdir / on startup. The problem is, if you mount a debina cd on /mnt, cd to /mnt, install some daemons, then /mnt is always busy after that and cannot be unmounted. The solution is to add a chdir / to the daemon's startup code or to the init.d script. A daemon that doesn't cd to /, or close all fd's, or set itself up as a session leader, is simply buggy upstream. Try to fix the C code rather than code around it in the /etc/init.d, and recommend to the upstream author that he buy a copy of Stevens Advanced Programming in the Unix Environment. Guy
Re: essential packages and Pre-Depends
Manoj Srivastava [EMAIL PROTECTED] writes: [If this discussion is restricted to essential packages, please ignore this message. I am quite confused now] Yes, we're just talking about essential packages. I agree with Santiago that all essential packages should be using Pre-Depends. After generating this list, I was surprised at how small it was. Required and Essential: (27) base-files base-passwd bash bsdutils debianutils diff dpkg e2fsprogs fileutils findutils grep gzip hostname ldso login mount ncurses-base ncurses-bin perl-base procps sed shellutils sysvinit tar textutils update util-linux Required, but not Essential: (20) adduser ae comerr2g e2fslibsg kbd ld.so libc6 libreadlineg2 makedev mawk mbr modconf modutils ncurses3.4 passwd setserial shadow sysklogd syslinux timezones Guy
Re: `du' control files
Nicolás Lichtmaier [EMAIL PROTECTED] writes: This du file is completely redundant. And it should be a bug in avery package that contains it. Yes, it's redundant now, but the du's of all the packages might be extracted and made available in some public place via http. That way deity could show you du info even if the deb wasn't available locally. Similar for the md5sum (du and it could be merged obviously), and the changelog. Guy
Re: PW#5-12: New upload procedure
[EMAIL PROTECTED] (Richard Braakman) writes: Should the installer check, before closing a bug, if that bug was reported to the source package (or one of its binary packages) that closes it? The installer will CC the bug closes to the maintainer, so she can confirm that the right ones were closed. The bug system will then ack to the maintainer also. This method is no more prone to failure than typing the address in the email by hand. Guy
Re: PW#5-12: New upload procedure
Ian Jackson [EMAIL PROTECTED] writes: There are two reasons I can think of at the moment for putting the parsing into dpkg-parsechangelog. Since Mike is planning to release a new dpkg very soon anyway, someone can just send him a patch and he'll include it. Guy
Re: beta software ok for unstable? (was: Re: policy Q's WRT imapd)
G John Lapeyre [EMAIL PROTECTED] writes: Where can I put a package that is not dangerous, and is functional, but is still in early stages of development? I imagine it might detract a bit from the rest of the stable distribution, and yet there are perhaps some who would like access to it. Unstable. I have no problem with a small subset of packages going to experimental. But a package which doesn't exist in unstable and isn't dangerous can certainly go to unstable. Guy
Re: PW#5-12: New upload procedure
Ian makes a good point that we shouldn't use different words to refer to the same action. So I'd go for closes rather than fixes. Regarding the re to use, I don't think we've relaxed it to such a degree that people will close things by accident. The only difference is that the original allows white space and ignores case. Guy
Re: RFC: New bug severity level fixed
Ian Jackson [EMAIL PROTECTED] writes: - bugs fixed by nmus but not therefore not closed - bugs fixed in unstable but not in stable - bugs where related discussion is still ongoing and the bug logs would be a useful reference I originally thought we would use it only for the first of these. The third doesn't make much sense. If serious discussion is still going on as to whether the fix was adequate, then the bug should be reopened. I don't think we would be using it for the second category either. Instead we might want a policy as to what kinds of bugs are fixed in stable. Possibly only critical? Guy
Re: lintian and e2fsprogs: doc-directory policy
James Troup [EMAIL PROTECTED] writes: IMHO this will lead to spurious Depends: being added to packages simply to satisfy 5.6. That would the tail wagging the dog. Packages which already depend on a sibling package don't need an additional copy of the copyright. I don't think maintainers would really apply the rule backwards like that. Guy
Re: Can NM close bugs in his/her NMR?
Marcelo E. Magallón [EMAIL PROTECTED] writes: Also, the approved policy states that a NM should not close bugs. But what if the bugs are only related to the NMR as in this case? Seems like it would be ok, but dinstall won't be able to differentiate it. It can differentiate NMU from MU and will either close them or set them to severity fixed. You'll still have to close them by hand after I upgrade dinstall to current policy. Guy
Re: PW#5-5: Standardized handling of /etc/init.d script options
Christian Schwarz [EMAIL PROTECTED] writes: On 15 Jan 1998, Guy Maor wrote: For programs which can't reload, I assume it would be ok to just let * handle it? Sorry, but I don't get your point. What is `*' ?? case $1 in start) start-stop-daemon ... ;; stop) start-stop-daemon ... ;; restart|force-restart) ;; *) echo Option not supported; exit 1 ;; esac Guy
Re: PW#5-2: Maintainer's reaction on non-maintainer uploads
[EMAIL PROTECTED] (Richard Braakman) writes: I think that any of these measures would be preferable to introducing a new class of fixed but open bugs. Such bugs would interfere with the attempts to use the bug system as an aid to release engineering, I don't think that there are so many nmus that this will become a problem. If it does become a problem, the easiest way to fix it would be to introduce a new severity which is lower even than wishlist for such nmu-fixed bugs. In the mean time, let's just write in the policy that nmus should not close bugs. The expired bugs really are removed, btw. Guy
Re: starting /etc/init.d/* from re-mountable media
Joey Hess [EMAIL PROTECTED] writes: I thought that it was common for daemons to cd / after they start up, to eliminate this problem?Won't that fix it? I think it's reasonable to expect daemons to have this behavior, and if syslogd or klogd doesn't, they are broken. Of course it's a bug in the daemon. See for example, W.R. Stevens Unix Network Programming 2.6 for the things you need to do when writing a daemon. And we shouldn't be enacting policy which compensates for others' bugs, adding cd / to every init.d script for example. We have the source, so we can fix the bugs directly. Guy
Re: PW#5-2: Maintainer's reaction on non-maintainer uploads
Gregor Hoffleit [EMAIL PROTECTED] writes: Regarding the notification about fixed bugs in nmu's: Is it really intentional that this way (what Christian and Guy propose) the fixed bugs won't be recorded anywhere in the package (since I can't list them in the changelog), but would only be visible from looking at the bugs database ? You can list them in the changelog. Just don't use the format that will cause a Fixes field to be added and dinstall to close them. Sorry, what does the last point mean ? Is it to say read the description of the patches and close the bug reports of the problems that are indeed fixed by the nmu ? No, read the descriptin of the patches and verify that the problems are indeed correctly fixed by the patches. Guy
Re: /bin/sh as an alternative
Adrian Bridgett [EMAIL PROTECTED] writes: Packages that contain scripts that use #!/bin/bash should depend on bash in case bash becomes a non-essential package bash will never become nonessential. Guy
Re: PW#5-12: New upload procedure
Christian Schwarz [EMAIL PROTECTED] writes: The idea behind this is the following: Currently, the developer announces the upload after having the file uploaded to Incoming. Since dinstall only runs once a day there is a slight chance that a severe bug is detected and fixed before dinstall processes the package. We'll use this possibility of dinstall sends the announcement after installing the package into the hierarchy. ok, that's reasonable. Would you prefer scanning the .changes file? It would certainly be easier to implement since this would not require any changes in dpkg-dev :) How about this - If there's a Fixes field, I'll use that. If not, I'll scan the changelog. Once a dpkg is available with a new dpkg-genchanges, I won't scan the changelog anymore. I was wondering why we need this feature, anyways. Wouldn't it be much better if dpkg-genchanges would add such an additional text to the .changes file? This way, the maintainer could easily change the text for each upload (which will be some work if the insertion file is sitting on master). Yes, that seems to be the right thing to do, and dpkg-genchanges already has the hooks to do it! What a forward-thinking person Ian is. Just add something like this to your control file: XC-Comment: As always, the files are available from my home page at http:// . Note that this upload does rm -rf / in the preinst. ... and the Comment line will appear in the .changes file. (Details in Packaging manual 3.2.2.1) I can move that field to the front in the posting, and throw in the file locations. Something like this: To: debian-devel-changes@lists.debian.org From: Debian Installer Subject: New package EraseEverything (source i386) installed. comment (if present) goes here Files were installed to: dists/unstable/main/binary-i386/... dists/unstable/source/binary-i386/... changes file goes here Guy
Re: PW#5-2: Maintainer's reaction on non-maintainer uploads
[EMAIL PROTECTED] (Kai Henningsen) writes: I thought we had agreed on * If the nmu fixes many bugs, close the bugs, but reopen a new one with the diffs No, there's often times valuable information in the bug report. What if the non-maintainer release doesn't correctly fix the bug? Only the maintainer should close the report. Guy
Re: PW#5-4: Gzipped symlinks
Christian Schwarz [EMAIL PROTECTED] writes: Though this works perfectly with man, it's completely controversal It doesn't work with xman. That should be reason enough not to do it. Guy
Re: PW#5-5: Standardized handling of /etc/init.d script options
Christian Schwarz [EMAIL PROTECTED] writes: force-reload if possible do a reload, otherwise restart Can anybody think of something better than `force-reload' for this option? All these options have to be provided by all scripts. If an option is not possible (i.e., the daemon does not support reloading) or fails, an appropriate error message has to be written to stderr and a non-zero error level has to be returned. For programs which can't reload, I assume it would be ok to just let * handle it? Guy
Re: PW#5-7: Linking shared libraries with -lc
Christian Schwarz [EMAIL PROTECTED] writes: One of the release goals for Debian 2.0 has been to link all shared libraries dynamically against each other. This can be done by using the `-lc' option when linking the library. With that, the library will contain valuable dependency information about which other libraries the library is linked against. The intention is right, but the technical details are wrong. Shared libs linked without -lc are still dynamically linked against libc (despite what ldd reports.) They just don't have an explicit dependency. I suggest the following: With the release of libc6, an explicit dependency on at least one of libc, libm, or libdl is required so that the dynamic linker knows which version of libc the library is using. Add the `-lc' option when linking the library. If you do this correctly, `ldconfig -p' will report your library as `ELF-libc5' or `ELF-libc6', and NOT as simply `ELF'. Guy
Re: PW#5-11: Policy on stripping static libraries
[EMAIL PROTECTED] (joost witteveen) writes: Sometimes one hears people say they need static binaries for security reasons Static libraries are useful when you want to compile something for people that might not be using a Debian system. For example, I've recently heard that the Redhat maintainer of libreadline decided to name it libreadline3 instead of libreadline2.1. If I wanted to compile some software that used libreadline, I had better statically link if I want everybody to be able to use it. We should continue to provide static libraries. We really shouldn't worry about the extra space they want. Hard drives are really cheap, and static libraries are small (for example, my /usr/lib/*.a are an average size of 357k). With that said, there are several suggestions here for what to do with the -dbg libraries. I'll try to summarize them. 1) Leave the symbols in the static libraries. Advangages - very simple. Disadvantages - -dbg code can't be coded in a special way (more output, more checks), need to download source and use directory command to tell gdb where it is. 2) Fabrizio's proposal Advantages - gdb finds code easily, User doesn't have to download code as a seperate file, code can be compiled with special checking flags. Disadvantages - wastes space on the ftp site, though since very few libraries provide -dbg (which is fine), it's not much space. Building -dbg libraries is (and will continue to be) optional. The problem is that there are several different methods currently used. I think we should hash out some policy so that all packages at least use the same method. Guy
Re: PW#5-12: New upload procedure
Christian Schwarz [EMAIL PROTECTED] writes: 3.) [check for new packages every ten minutes] Check if package upload was complete and the files are correct (i.e. check PGP signature, MD5 sums, correct .changes file, etc.) If there is an error send mail to the maintainer and stop 4.) Send announcement to debian-devel-changes in case of an unstable or experimental upload 5.) [once a day] Install packages into the archive (In case of a new package or a stable upload, this requires the acknowledgement of the archive maintainer) Is all that really necessary? Currently dinstall runs once a day, rejects anything which fails pgp, md5, etc, and installs anything it can. I can announce the package as soon as dinstall sees it, even if it's new and might not get installed immediately. If someone is really burning to know if their upload is ok and they can't wait, they can run `dinstall -n foo.changes'. Fixes: 98765 98766 9 So dinstall will be scanning for this field, and not looking in the changelog? In other words, this will only work for people that have an updated dpkg-genchanges? 2. Before sending the announcement of the package upload, dinstall will check the maintainer's home directory on master if it contains a `~/.changes-template' file, in which case the file contents will be dinstall will only do this if the maintainer address is [EMAIL PROTECTED], as the files' UID is wrong when it's coming from one of the upload queues. Guy
Re: PW#5-13: New virtual packages
Christian Schwarz [EMAIL PROTECTED] writes: As long as bash is tagged `Essential: Yes', I don't think we need special dependencies for posix-shell. Yes. However, managing /bin/sh through alternatives sounds like a good idea to me. Yes. I already have a bug report to do this. Waiting until just after hamm is released is probably safest. Guy
Re: Implementation of Developer's DB
Christian Schwarz [EMAIL PROTECTED] writes: Don't believe me? Just let me note, that all packages that are currently maintained by a group of developers, have a much longer list of outstanding bug reports than most one-maintainer packages, for example dpkg, boot-floppies, doc-debian containing the FAQ (not much bugs, but the FAQ is actually orphaned). Oh come on. Maybe it's more related to the fact that it's the most complicated packages that need more than one person to maintain them. Guy
Re: Policy for group ownership of games (Was: Re: Bug#15846: rocks-n-diamonds: errors on startup)
Joost Kooij [EMAIL PROTECTED] writes: Now, should the rocksndiamonds group be done away with? Yes. Guy
Re: Policy about use of upstream source as .orig.tar.gz
Will Lowe [EMAIL PROTECTED] writes: 1) Unzip the source and move it into the right directory: tar -xvzf package.version.tar.gz mv package.version/ whatever-version 2) rename the tar.gz mv package.version.tar.gz package-version.tar.gz Should be ^^^ package-version.orig.tar.gz. Guy
Re: Rationale for /etc/init.d/* being conffiles?
David Frey [EMAIL PROTECTED] writes: AFAIK, dpkg does only ask when the md5sum of the conffile changed. So if it didn't change, you get the old version. dpkg asks when the md5sums of both versions - the one on your system and the one in the package - change. Guy
Re: Policy for group ownership of games (Was: Re: Bug#15846: rocks-n-diamonds: errors on startup)
Joost Kooij [EMAIL PROTECTED] writes: How about adding a group gamesadmin to the system and making all level definitions etc. owned by this group. Sounds like overkill to me. I think you should go with the simple solution - the builtin levels are not writable, but you can specify levels from the command line. Users can then just put levels in their home dirs, and they can let other people play them if they want. Guy
Re: Do we want /usr/libexec ?
Christian Schwarz [EMAIL PROTECTED] writes: If noone objects, I'd prepare a policy change to forbid the use of /usr/libexec. As the FSSTND already implicitly forbids it, I don't think that's necessary. Guy
Re: Policy Weekly Issue #4/3: Guidelines for Motif applications
Christian Schwarz [EMAIL PROTECTED] writes: Note, that packages that require non-free Motif libraries can't go into the main distribution. Add to this paragraph: If your package is free otherwise, it should go into contrib. Otherwise it must go into non-free. And add another paragraph recommending lesstif: If your package works reliably with lesstif, you should package it with lesstif, and not with Motif at all. It's fine otherwise. Guy
Re: Policy Weekly Issue #4/1: Bash vs Bourne shell
Santiago Vila Doncel [EMAIL PROTECTED] writes: On Thu, 23 Oct 1997, Christian Schwarz wrote: ``The shell `/bin/sh' may be symbolic link to any POSIX compatible shell. If a script uses non-POSIX features the appropriate shell has to be specified in the first line of the script (i.e. `#!/bin/bash') and the package has to depend on the package providing the shell (unless the shell package is marked `Essential').'' This is ok, but I would object if it simply stops there. I think something like the following would have to be added: ``For portability reasons, you must use POSIX syntax wherever possible.'' Yes, you wrote the admonition without the encouragement. To elaborate on Santiago's addition: Restrict your script to POSIX features when possible so that it may use /bin/sh as its interpreter. If your script works with ash, it's probably POSIX compliant, but if you are in doubt, use /bin/bash. Guy
Re: Policy Weekly Issue #4/6: Secure maintainer scripts
Joey Hess [EMAIL PROTECTED] writes: Christian Schwarz wrote: I don't think this is good enough. The point isn't really to do this, it's to create files in /tmp in a secure manner. Uh, yes: The Debian base distribution provides the `tempfile' utility for use by scripts for this purpose. Use of tempfile should be required. As you already know, there's a new BSD script with does the same thing as tempfile, but may be more standard. So hold off on this section of the policy until I get this new program into debianutils. After that we should mandate its use (assuming it has at least tempfile's capabilities). I'll keep tempfile in debianutils until nobody uses it though. Guy
Re: perl-base
Scott Ellis [EMAIL PROTECTED] writes: Perl will suppliment perl-base, not replace it (if I've gotten this correct). You have. Guy
Re: Bug#13287: less uses /usr/bin/editor without it necessarily being there.
Christian Schwarz [EMAIL PROTECTED] writes:
1. The base system has to provide initial settings for
/usr/bin/{pager,editor}.
This is implemented for pager with util-linux 2.7.1 providing more.
(less also provides an alternative, but it's not in the base system.)
Guy
Re: issue 03 : handling upcoming fhs draft
Andreas Jellinghaus [EMAIL PROTECTED] writes: so packages already designed to fit fhs are ok, or do i need to move and patch till i die^H^H^H^H^Hfhs is released ? Unfortunately, yes. Guy
Re: perl-base
Jim Pick [EMAIL PROTECTED] writes: e) move the modules from dpkg-perl to dpkg. No. The dpkg package is already too bloated. If we add dpkg-perl to it, then we should add dpkg-python too. And then we have to update dpkg everytime we fiddle with the interfaces in these relatively immature packages. We should try to minimize the number of updates to dpkg, since that makes it easier to trace back problems to a specific revision. ok, that's reasonable. If the interfaces were mature, they could go with dpkg. libdpkg is there. Personally, I'd like to see the dpkg package shrink. dselect could be a separate package from dpkg. A few of the larger things in dpkg should be dpkg-dev - /usr/doc/dpkg/packaging.html/* /usr/include/dpkg/* /usr/lib/libdpkg.a Moving those would knock about 1/3 off its size. I'll file a bug report. Guy
