Re: New ftp method for dselect
Dirk Eddelbuettel writes (supercite undone - iwj): [Ian Jackson writes:] Right. In order to avoid having to rename lots of packages or change their version numbers I propose the following naming scheme for files on the FTP site in the `binary' directory: package-name--version[-revision].deb Note the two hyphens. Could such a measure be announced 24 to 48 hours in advance, and ideally be complemented by a script that can be used for renaming the files on the local tree? Yes, of course. Otherwise folks like me will have to refetch about 110 Megabytes of */binary/* stuff. Not that much fun over a phone line. Some people even have to pay for every bytes they get through their phone. Indeed. Ian.
Re: New ftp method for dselect
Bill Mitchell writes (Re: New ftp method for dselect): dchanges(1) seems to parse distribution filenames OK, though the parsing code is pretty ugly. If it's broken, please let me know. Seems to do it OK isn't good enough - we need something unambiguous and predictable. Ian.
Re: New ftp method for dselect
David Engel writes (Re: New ftp method for dselect): OK, so package file names don't parse easily. Why couldn't the cross reference be included in the Packages file? It's needed by dselect anyway. Also, what about packages like ld.so where the file name doesn't match the package name (ldso)? What am I missing? There already is a cross-reference in the Packages file. However, the dselect ftp method needs to be able to recognise what a file is even in the gap between the file being moved into view and the Packages file being updated. Otherwise it would have to download it `on spec'. Ian.
Bug#1995: run-parts on laptops
Raul Miller writes (Re: Bug#1995: run-parts on laptops): I think there's a good answer to this question, but I doubt the above workaround to the current package implementation of cron will occur to very many people. How about taking cron out of rc*.d ? Ian.
Re: Incoming file permissions
Dale Miller writes (Incoming file permissions): I noticed that some but not all of the new packages that get uploaded to the Incoming directory don't have read permissions. Is there a reason for this? Are they uploaded that way? I like to install the latest and greatest as quick as possible. I know, that could be asking for trouble but that's me. I am particularily interested in the dmalloc package that just came out but couldn't get it for the past couple of days. If there is a reason why it is like that then no problem. I was jsut curious why only part of the packages were uploaded that way. The packages that come via my system are uploaded using rcp rather than anon-ftp, and so have more standard default permissions. Ian.
Re: Bug#2048: Broken pipe from dpkg to head
Bill Mitchell writes (Bug#2048: Broken pipe from dpkg to head): root:work# dpkg --info less*deb | head -1 old debian package, version 0.939000. Broken pipe Richard Kettlewell writes (Bug#2048: Broken pipe from dpkg to head): [EMAIL PROTECTED]:richard$ ls -l | head -1 total 19792 Broken pipe [EMAIL PROTECTED]:richard$ Quite. I'm marking this as done. RTFM bash(1). Ian.
Re: Package Verification
brian white writes (Re: Package Verification ): This is fine, but it doesn't help with verifying packages on non-Debian systems as is required by people who must do an actual FTP from another machine. As for the format, feel free to alter it. I figured I would be parsing this line out of the Packages file, anyway. As long as it has file size, there is at least some sort of verification that can be done regardless of the machine being used. I suppose we could put the file size in the Packages file; it just might get a bit cluttered with all of this information. What do people feel about this ? Ian.
Re: psutils ELF package release
Dale Scheetz writes (psutils ELF package release): As I have not yet obtained the upstream source, I have been unable to create a diff file for this package (I had to fake out dchanges with a fraud .diff.gz file). Do not upload the package without a diff. It's incomplete. Please get the original source - the debian.README says where. It is my understanding (please correct me if I am incorrect) that the .diff file is to reflect the difference between the debian source and the original upstream source so that the original source can be recreated from the debian source. Asside from the debian control files this source is the same as the previous version. No, the .diff is to build the Debian package from the source, and to see what changed. Ian M.: please don't move any of these packages with fake diffs. Ian.
Re: ncurses-1.9.8a ELF release
Let's say I have a package named foo-n with a shared library in it named libfoo.so.x.y that, at least for the time being, must always be available by that name, even while dpkg is moving things around. Now, at some point in the future, I know that libfoo.so.x.y whill no longer be needed for any number of reasons. What I'd like to be able to do after dpkg is done upgrading foo-n with foo-m, removing foo-n completely or replacing foo-n with bar-p, is have libfoo.x.y deleted, if and only if, no remaining package claims to own libfoo.x.y. Can this be done, and if so, how? Claims to own? Do you mean claims to need ? No! By own, I mean that the file belongs to a package and shows up when running dpkg -L on that package. I'm assuming that dpkg's normal dependency checking won't allow the package to be removed while others still depend on/need it. Ah, right. In that case, the answer is that dpkg does this already - but it does it (removes the old libfoo.x.y) before th the postinst runs. Plain files are oonly in one package at once. What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the new libc.so.5.2.7. The link needs to be changed to point at 5.2.9 when *both* files are available, surely, as otherwise it will point into nowhere for a bit ? Now I'm confused. That part of my message was in reference to your comment on category 1 packages where you contradicted yourself. Did you mean category 2 instead? Here is the relevant section from your earlier message: Yes, I did mean categoory 2 instead. Is this getting any clearer ? :-/ Ian.
Re: Unanswered problem reports by maintainer
Carl Streeter writes (Re: Unanswered problem reports by maintainer): On Tue, 26 Dec 1995, Raul Miller wrote: URL: http://www.cps.cmich.edu/~streeter/debian-bugs/ http://www.debian.org/Bugs. Ian.. Could you update this? Done. (I've been away - I'll catch up with my email in the next few days ...) If anyone spots any references to the old URL could they let me know ? I'll be uploading new bug-*.txt files to ftp.debian.org shortly. Ian.
Re: ncurses-1.9.8a ELF release
David Engel writes (Re: ncurses-1.9.8a ELF release): Slowly. I've been trying to better understand how dpkg works and find a way to do what I want with the current behaviour. The only way I've come up with is rather ugly and probably error prone so I haven't even bother to hash it all out. If you'll answer me a couple of questions, I'll try to come up with a cleaner way that would only require a minimum of changes to dpkg. Here they are: Can, and if so how, dpkg/dselect remove one package and replace it with another in one invocation? Yes. There are some restrictions - most importantly, that the package being replaced be deselected first, or that both the new and old packages be marked essential. Usually dselect and the Conflicts mechanism will handle that bit. You can replace only one package at a time, but an upgrade can replace one other package as well as the previous version of the package being installed. Does dpkg/dselect allow a package to be upgraded or replced with another and then left in an unconfigured state? Yes, it does. This is necessary to avoid having ordering restrictions on the bulk transfer part of the installation. Basically, what I'm concerned with is the time between an old package's postrm script being called and any new package's postinst being called. I think you need to read project/standards/maintainer-script-args.txt - it describes in some detail exactly what happens when and which scripts get called. Ian.
Bug summaries by maintainer
These listings have been using out-of-date overrides file and Packages file information, because the cron job to update my local copy wasn't working. I think I've fixed that now, and the next summary should be correct. Please let me know of any further problems. Thanks, Ian. (BTW: I've just caught up with my personal mail here; I still have about 100 debian-devel messages marked to save or reply to, which I won't get around to today. Please bear with me ...)
Re: New ftp method for dselect
Robert Leslie writes (Re: New ftp method for dselect): Exceptions: (the ones I saw, anyway) stable/binary/net/bind-4.9.3-BETA24-1.deb debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb If there are no objections I think I will rename the next version of the bind package to something like: bind-4.9.3BETA26-3.* Hopefully this will be kinder to software needing to parse package names. Well, I was going to object, but I see that you've already done it. You might like to consider reversing the change so that people can upgrade without having to invoke dpkg manually (dselect invokes it with --refuse-downgrade). I'll be posting later about how I think the FTP method should be done. Ian.
Re: Buglist
Sven Rudolph writes (Re: Buglist): Some suggestions for the bug reporting system: - It is possible to mark a message quiet in order to get it not echoed at debian-devel. Is there a way to make answers to it be not echoed too ? (e.g. by introducing a debian-bugs-quiet alias) That might be a good idea. Bruce, could we do that ? This is probably better than that horrible thing with `X-Debian-PR: quiet' in the main mail header. - Or what do you think about moving all bug-system messages to another mailing list ? - There was a suggestion that bug reports are directly sent to the package maintainer. Is this still planned ? How about having most bug reports still go to debian-devel, so that people can comment if they see something that touches on their `area', but make debian-bugs-quiet available so that the submitter can send things only to the maintainer ? Ian.
Re: apache
Miquel van Smoorenburg writes (apache): Well, my views on this are: o a /var/httpd/htdocs for the documents Remember apache can be a server for multiple domains. That's why we need a 2-level directory structure; you might get /var/httpd/htdocs-customer2 /var/httpd/htdocs-customer3 as htdocs base directory for other virtual domains. The cern-httpd package creates a `www' user and an entry in /home/www. I think this is probably a better idea. Ian.
Re: binary-alpha and binary-sparc directories
(Crosspost to -alpha and -sparc removed.) Bill Mitchell writes (Re: binary-alpha and binary-sparc directories): It seems that the Guidelines document needs updating to address issues falling out of this. One issue is whether binary packages are to be distinguished by distribution-specific naming convention (and, if so, what that convention is to be). Binary packages will need need distinguishing names if they're to be uploaded to a common Incoming directory. As Matt Bailey suggests, I think separate Incoming directories is a better solution. If we encode the architecture into the filename it will become excessively long, and directory listings will contain much useless junk. Will debian systems offer cross-compilation facilities? Will the developer of a sparc-targeted package be expected to provide an i386 build as well? If not, and some other developer provides the i386-targeted package, which of the two source packages (which may differ from one another) will be in the distribution? Debian packages can't (in general) be cross-compiled for different architectures. We can't make a requirement that this should be possible, because not all upstream source could be made to meet it. I expect that most packages would have a `primary' Debian maintainer, and that people doing ports would just upload binaries. If they need to make changes to the source they will have to work closely with the `primary' maintainer to ensure that all the sources are kept in step. It seems to me that packages will need a primary maintainer, who would be responsible for the source package, and an architecture specific maintainer for each supported binary package. One person could act in all capacities, of course, but I'd expect that at least some packages would have different maintainers for the different architectures. The way I see this working, architecture-specific maintainers with the ability to address architecture-specific bug reports and do architecture-specific testing would feed architecture-specific fixes and patches to the primary package maintainer. Primary package maintainers having, say, a sparc would install alpha or i386 patches blindly, relying on the testing done by the alpha and i386 maintainers, and issue a package revision update. Yes. Ian.
Bug#2060: dpkg and depends on version again
Erick Branderhorst writes (Bug#2060: dpkg and depends on version again): [...] The character is misleading and in practice it is interpretated by dpkg as =. I would suggest to change the syntax used in Depends/Conflict/Provides/Recommends/Suggest fields into a more intuitive way (Table 2). [...] However, changing this now will break almost every Debian installation. A way to prevent is is to prevent building new packages with Depends/Conflict/etc fields with or in it, and notify the maintainer to change this to = or =. Installation rules should remain the same until no more packages have or in it. For consistency a = character should be allowed to indicate that the mentioned version is requested. How about = = for less/greater than or equal to for strictly less/greater than for less/greater than or equal to (backwards compatibility, generates warning from dpkg-deb) = for equal to ? = is supported already. Ian.
Bug#2059: dpkg and depend on versions
Erick Branderhorst writes (Bug#2059: dpkg and depend on versions): Package: dpkg Version: 1.0.8 I installed the man package (2.3.10-6) succesfully. After that I tried to upgrade the libgdbm1 package (1.7.3-8). During installation of libgdbm1 dpkg reports about libgdbm1 conflicting with man (2.3.10-6) and that man (version 2.3.10-5) is installed. Are you absolutely sure that this is what it is doing ? Was the thing below an actual session transcript ? I find it hard to imagine where it got the `5' from ... Note that means less-than-or-equal-to in this context. Ian.
Re: binary-alpha and binary-sparc directories
Michael K. Johnson writes (Re: binary-alpha and binary-sparc directories ): Ian Murdock writes: [...] ther have to have separate Incoming directories for all supported architectures, or we'll have to have a naming scheme for all Incoming binary packages (prepending a dash and the architecture name, for example) that can be easily resolved before the packages are moved. Consider the case of independently-distributed .deb files. You don't want to make people put them into different directories if they support multiple architectures. I strongly suggest that putting the arch into the name will be a lot of help in the long term. Why can't people who want to put multiple .deb files for different architectures in the same directory rename the files ? Ian.
Bug#2081: named does not start
Michael Alan Dorman writes (Bug#2081: named does not start): In message [EMAIL PROTECTED], Jean-Marc Bourguet w rites: PS=`ps -p $PID 2/dev/null| tail -1 | grep named` You might want to make this PS=`ps -p $PID 2/dev/null| tail -1 | grep named | grep -v grep` so that it doesn't pick up the grep process as well. Don't do things like this in production code. What if some poor user's process happens to contain the string `named' ? This is what programs like start-stop-daemon are for. (I'm glad to see that the package maintainer has fixed the problem, I'm just pointing out that this kind of trick with ps may be all very well for a quick hack, but that Debian isn't just a quick hack.) Ian.
Re: Too much information! (And what to do about it.)
Ian Murdock writes (Too much information! (And what to do about it.)): With all of the new developers that are joining the Project and the number of new packages that are resulting from their involvement, it's becoming increasingly difficult, especially for newer users who aren't exactly sure what to look for, to browse the archive of packages without becoming overwhelmed at its sheer size. It's certainly great that all of these new packages are becoming available, but it's also presenting a problem for us, a problem which we need to address soon. What I propose we do is separate the distribution or system packages (those packages that constitute a complete system--definitely Base, Important, and Standard packages, and possibly Optional packages, too) from the application or extra packages that generally wouldn't be considered part of an operating system. With two such trees, the distribution would be far easier to manage. Comments? Now would be the perfect time to do something like this; many mirror sites are going to have to redownload everything anyway. In principle this sounds like a good idea. I don't have a strong opinion on whether Optional should be included in the `distribution'. However, it would be good if you don't break dselect's access methods c. These expect to find `stable', `development', `contrib' and `non-free' at the top level, and inside each a `binary' directory and in there a `Packages.gz' file. If you could make the split under there, by splitting each section into two directories, that would work better, I think. I think we should discuss this a bit before it gets done. Ian.
Re: Bug#2091: creating packages requires root privileges
Marek Michalkiewicz writes (Bug#2091: creating packages requires root privileges): To create a binary *.deb package, root privileges are required. This is because you must create a complete directory structure with proper ownerships and permissions first, and then use dpkg-deb to create a package from it. Unfortunately there's not much that can be done about this, because most packages are created by running the package's own Makefile to install the files. This doesn't work (or fails to DTRT) if you're not root. I have no plans to improve this situatioon; I think the simplest solution would be a way to mount a part of a filesystem in a way that means user uid is root for here. You'd want to mount it with nosuid,nodev of course. Then the filesystem could be used to record the chmod's c done by the package build Makefiles and get them into the .deb file. If someone else wants to write a program that makes .deb files some other way then they should feel free. They'll probably want to make the `new format' archives the default - see the dpkg-deb source for details. I'm closing this bug report. Ian.
Re: FTP site performance low
Matthew Bailey writes (Re: FTP site performance low): [...] Well netscape corp screwed me with politics and listed me in their mirror listings. Well there used to be more mirrors but it seems that we are one of three listed now. And until beta 5 or release version are out I can not get out of their list. And I can not remove their software until this happens. Well, you seem to be more tolerant than me. I hope they're paying you well for the privilege of being swamped for their commercial benefit. If they're not I'd just say to them Either you take me out of that list by date or I remove Netscape. Up to you. But then I'm a bastard :-). Ian.
Re: binary-alpha and binary-sparc directories
(Gigantic crosspost trimmed.) Raul Miller writes (Re: binary-alpha and binary-sparc directories): It does look like dvips was superceeded by some other package, and that it did originally have some executables in it. [All I have on my system from dvips is a copyright statement and some .tex files]. makeidx, metafont and xdvi also seem to be mere stubs of packages on my system. dvipsk should have a Conflicts line to ensure that dselect/dpkg will remove dvips. /usr/bin/fort77 is a perl script, the only other things I see in this package are a man page and a copyright statement. Since I have f2c on my system as a separate package, I'd guess that fort77 has also been superceeded... Again, a Conflicts line would have done the right thing. I think this is a bug in the debian packaging mechanisms. Well, I could change dpkg so that it would barf in this situation, rather than going ahead and removing the files from the earlier package, but I think that would have been less helpful. Ian.
Bug#2080: cern-httpd or dpkg leaves log files after purge.
David H. Silber writes (Bug#2080: cern-httpd or dpkg leaves log files after purge.): Package: cern-httpd -or- dpkg Version: ??? 1.0.7 After purging cern-httpd from my system, the log files remained. The logfiles will be created by the package, so dpkg doesn't know anything about them. It is cern-httpd's responsibility to clean them up. Thanks, Ian.
Bug#1995: run-parts on laptops
Raul Miller writes (Re: Bug#1995: run-parts on laptops): Ian Jackson: Perhaps savelog should be moved into another package, then ? This seems like a very good idea. miscutils is probably the right one. Ian.
dselect FTP method and dftp wrt FTP site organisation
While thinking about this problem over the Christmas break I have come to the conclusion that we do not have to change the filenames so that we can recover the package name and version information from them. Programs can use the Packages file to avoid downloading files that they know they don't want (because of the Filename field there). If a package has just been moved into view and the Packages file isn't up to date yet then they will have to download just enough of the package to get the control information and can then abort the transfer. Because most of the schemes for making the filenames contain the package name and version without any ambiguity are ugly in some respect I'm inclined to say that this is what we should do. There is another problem with encoding things like this: it means that if at some later point we want to put some new information in the filename (such as the target architecture) we can't do it because it will break dftp and the dselect FTP method. There are a couple of things I want to set people straight on, in this area: * dpkg and other packages written especially for Debian don't have a revision number because a revision number would be meaningless and confusing. The most recent guidelines say not to use the Revision field anyway (as it will be phased out soon) and say that only packages not written specially for Debian shouldn't have a -revision component in their Version field. * Changing the format of version numbers in existing packages causes problems, because dpkg can't tell whether the package is a downgrade and so can't tell whether to install it. * Noone (hopefully) is proposing changing the actual package names (as seen inside the package control file), so consideration of Provides fields as a backwards-compatibility measure is missing the point. Changing package names is quite a serious and risky operation for an already-installed system, and should be avoided where at all possible. * Someone said that we don't need to parse the version number out of the filenames. They were wrong. dftp and the dselect FTP method need to know the version numbers of packages they're thinking about downloading, so that incremental upgrades don't have to fetch all the selected packages but only the changed ones. * There is little point trying to keep our filenames completely consistent with the upstream maintainers'. In fact, upstream maintainers' filenames are frequently very inconsistent across packages, and we want to present a consistent filename format for neatness. * If we do want to rename all the .deb files we don't have to do it all at once and screw up the mirrors. Just rename half a dozen files each day until they're all done. * Revisions are allowed to contain `.' characters. See the packaging guidelines. * A SITE EXEC command is no good because we can't rely on it being supported everywhere. It's also quite inefficient. * Bruce said: Once we decide on a package naming standard, we should tell the rest of the free software world what it is and encourage the upstream maintainers to stick to that format. There already is a de-facto standard for general naming of upstream source packages - it's the one used by the GNU people, package-version.tar.gz. Ian.
Re: dist-3.60-3 uploaded to ftp.debian.org
Manoj Srivastava writes (dist-3.60-3 uploaded to ftp.debian.org): * Use /etc/news/organization instead of /etc/organization Please note that people who installed mailagent-3.44-1 and/or dist-3.60-2 shall have to remove /etc/organization manually after upgrading both packages. Can't you fix this up in the postinst ? Ian.
Packages files now contain `size' and `md5sum'
I've updated mkpackages so that it puts the size in bytes and MD5 checksum of the files in the Packages files. I didn't put them in the same field because it seemed silly for programs and humans to have to parse the contents of a field into two essentially unrelated pieces of information, and because I couldn't think of a good field name :-). The actual Packages files are being updated as I write this. I've also changed mkpackages to leave out any empty fields that might have been in the original packages' control files. Ian.
Re: binary-alpha and binary-sparc directories
Bill Mitchell writes (Re: binary-alpha and binary-sparc directories): This seems shakey -- especially if we posit that the i386 maintainer is in the U.S., the Mac maintainer in Germany, and the PowerPC maintainer in Korea. Also, the upstream source maintainer might be in Romania, and might not be be interested in picking up the Mac and PowerPC changes which our maintainers have made to his source code. The (primary) maintainer of a package is the one who maintains the *source*. They may not necessarily build the i386 binary, perhaps only the m68k or some such. A Debian source package should compile under any architecture (unless its function is inherently architecture-specific). If it doesn't it is a bug which it is the responsibility of the primary maintainer to fix. If the primary maintainer doesn't fix it we should consider the package orphaned, and then the person trying to build for another architecture can upload their source as the generic source, either officially taking over the package or just putting out an `interim' release. There's no problem, btw, with having several source versions in the FTP site. We should only delete an old source version when all the old binaries have been replaced with the new ones (this is a GPL requirement, amongst other things). Ian.
Re: ftp method v2
Andy Guy writes (ftp method v2): eg, if: Filename: development/binary/text/a2gs-1.0-4.deb looks for a2gs-1.0-4.deb in the ls -lR listing (it will probably find it in text/ !). If it cannot find a Filename field it falls back on using pkgname-ver[-rev].deb. That's an improvement, but still not foolproof. Can you get it to download just the start of the file and then abort the transfer ? WHAT TO DO: To install, untar the attached file and copy into /usr/lib/dpkg/methods/ftp Can you recommend people put this in /usr/local/lib/dpkg/methods, please ? That way if anything breaks it will be obvious what is part of the dpkg package proper and what is locally installed. Compile the dvercmp.c file, and put the executable some where in the default path (/usr/local/bin) Create a directory /var/lib/dpkg/methods/ftp You could supply a tarfile that contains /usr/local/lib/dpkg/methods/ftp/... /var/lib/dpkg/methods/ftp/ [empty directory] /usr/local/bin/dvercmp perhaps. Install: [ description ] Does this mean that you have to have enough spare disk space to contain all the files you're installing ? WARNING: [...] To interface to ftp program it creates a .netrc file (there is no way to use an alternate .netrc file from ftp -- arrggghhh), it tries to keep your current .netrc intact and not leave a .netrc lying around at the end - but it may. Why not do without a netrc and use `ftp -n' and `user anonymous email' ? I havn't changed the default .deb filename to include two hyphens, it is a trival change but not really necessary now I use the Filename: field. That's fine, thanks. Ian.
Bug#2059: dpkg and depend on versions
Erick Branderhorst writes (Re: Bug#2059: dpkg and depend on versions): Yes, I'm sure, the transcription was in chronological order. I didn't understand the `5' either. Chronological order ? I was thinking that perhaps the was causing it? Is the conflicting version number calculated from (2.3.10-6) or is it displayed right away after reading it from the status file. I should have send the status file probably but I think it is too late now. The conflicting version number isn't *calculated* at all, it just comes out of dpkg's idea of what's in the status file ... If you can't reproduce this I suppose I'll have to close the report. Ian.
Re: binary-alpha and binary-sparc directories
Raul Miller writes (Re: binary-alpha and binary-sparc directories): How about the option of a better record of what has happened? For example, currently, if multiple packages supply the same file only the most recently installed package has the files listed in it's .list file. If we have package installation time recorded, we wouldn't lose any information if (a) all packages which supplied a file had the file listed in their .list files. (b) the default behavior of dpkg would be to not remove a file till all packages with references to it were removed. This makes sense. I think I'll have to support `Replaces' or something, so that old packages can have all their files `taken away' and disappear eventually. If it's a speed issue, perhaps I should spend some time profiling dpkg? No, it's not a speed issue - it's a question of deciding what the behaviour should be and then me finding time to implement it. I've added this to the wishlist ... Ian.
Bug#2060: dpkg and depends on version again
Erick Branderhorst writes (Re: Bug#2060: dpkg and depends on version again): How about = = for less/greater than or equal to Ok for strictly less/greater thani Ok for less/greater than or equal to (backwards compatibility, generates warning from dpkg-deb) Ok but an fatal error from dpkg-deb would be better than just a warning. = for equal to You're right, of course. Pleasing symmetry is often appropriate, but not here I think. = = less/greater or equal strictly less/greater less/greater or equal - produces warning from dpkg --build Erick Branderhorst writes (Re: Bug#2060: dpkg and depends on version again): Ok but an fatal error from dpkg-deb would be better than just a warning. Bill Mitchell writes (Re: Bug#2060: dpkg and depends on version again): How about no warning on package config/install operations, and a fatal error on package-build operations? No, because that breaks existing source packages. Ian.
Re: new syslogd
Dale Scheetz writes (Re: new syslogd): ... Well, sysklogd conflicts with syslogd. I assume this means that it conflicts with it's conffiles too? No. The thought was that this could be why dselect has problems with syslogd and sysklogd. Could you please elaborate on these problems ? Ian.
Bug#3327: cern-httpd postinst hangs if daemon configured for inetd
Package: cern-httpd Version: 3.0-6 The cern-httpd postinst tries to start the daemon, like this: start-stop-daemon --start --quiet --oknodo --exec /usr/sbin/cern-httpd If the server is configured to run out of inetd, as I have it, this (probably) runs cern-httpd and hangs. If you type an HTTP request into it it works and marks the package configured, as desired. My lightly edited cern-httpd.conf is below. Ian. # This file was automatically generated by the postinstallation script. # # # Sample configuration file for cern_httpd for running it # as a normal HTTP server. # # See: # http://www.w3.org/hypertext/WWW/Daemon/User/Config/Overview.html # # for more information. # # Written by: # Ari Luotonen April 1994 [EMAIL PROTECTED] # # Minimally Hacked for Debian GNU/Linux by: # Ted HajekAprli 1995[EMAIL PROTECTED] # # Set this to point to the directory where you unpacked this # distribution, or wherever you want httpd to have its home # ServerRoot /usr/lib/cern-httpd # # The default port for HTTP is 80; if you are not root you have # to use a port above 1024; good defaults are 8000, 8001, 8080 # # Port 80 # # General setup; on some systems, like HP, nobody is defined so # that setuid() fails; in those cases use a different user id. # UserId nobody GroupId nogroup # # Logging; if you want logging uncomment these lines and specify # locations for your access and error logs # AccessLog /var/log/httpd/access.log ErrorLog/var/log/httpd/error.log LogFormat Common LogTime LocalTime # # User-supported directories under ~/(UserDir) # UserDir public-html # # Scripts; URLs starting with /cgi-bin/ will be understood as # script calls in the directory /your/script/directory # Exec/cgi-bin/* /usr/lib/cern-httpd/cgi-bin/* # # URL translation rules; default location of documents. # Pass/* /home/www/*
Re: Porting and the bug reporting system
Martin Schulze writes (Re: Porting and the bug reporting system): ... But as Michael said, the bugtracking system has a long backlock. Your bugs won't reach the maintainer until Ian has repaired it. The bug tracking system is now working fine, and answering mail almost immediately. The only thing still waiting to be resolved is that the WWW logs are still rather out of date, but this will be fixed when www.debian.org (= debian.microworld.net) catches up with mirroring master. The logs on www.cl.cam.ac.uk are stalled waiting for effort from the mail admin here. When all the mirrors are up to date you'll be able to find the WWW bug logs in the WebPages subdirectory - they're already fine on master. In the meantime you could try using URL:ftp://master.debian.org/pub/Linux/debian/Bugs/index.html URL:ftp://master.debian.org/pub/Linux/debian/Bugs/db/index.html (FTP doesn't do quite the right thing with directories - it fails to use index.html). master's ftpd appears to be shut off at the moment. No maintainer would read all your tons of bugreports that were sent to debian-devel, If the bug report has a correct Package line and the Maintainers file on the FTP site has the right address in it the maintainer will get a copy of the bug report sent to them directly. These bugs should have been sent to [EMAIL PROTECTED], to stop them from flooding debian-devel, but otherwise reporting them as bugs is OK. They should have been submitted with appropriate Subject lines. I'd be grateful if someone - the original submitter, perhaps - would use the `retitle' command at [EMAIL PROTECTED] to give them all meaningful Subjects. I do hope we don't have anyone around here who gets upset just because someone files a bug against their package, provided that the bug report isn't daft. We should be encouraging feedback. Ian.
Source packaging - alternatives
I've been reading the discussion ...
Firstly, I'm glad to have disposed of the `byte-for-byte original
source archive' idea (and that some of the people I thought were
advocating this were merely advocating that we should be able to
extract the original source files somehow from our source archive,
perhaps in a differently named directory or some such).
It seems to me that the `we want a single file' idea is perhaps
starting to be a problem, and that some of the alternatives people
have suggested may have some merit.
I'll therefore describe to you an alternative proposal to the one I
described last weekend (the one with a single `ar' archive). I'd like
to see more discussion about this, as I'm still not convinced that all
the possible issues have been raised.
Please don't bother having long flamewars about the merits of one
thing versus another if you're just trying to convince the other
people of your correctness. It's me and Bruce you need to convince, I
think :-).
Here's the alternative I've dreamed up:
* The source package is three files:
- hello_1.4-3.dsc
DSC= Debian Source Control (suggestions for better extensions
welcome). This contains a dchanges/debian.control-like format, for
example:
Source: hello
Version: 1.4-3
Architecture: any
Depends: gcc { standard dpkg control file syntax }
Generates: hello { names of binary packages, comma-separated }
Data-MD5sums:
faa56f7d564b1972f66a2d17ddf97413 hello_1.3-4.diff.gz
d2cb670eee141fc08eaa4a794b8b68fe hello_1.3.orig.tar.gz
This would optionally be PGP-signed. The `Architecture: any' means
that the source is arch-independent, but the binary isn't.
`Architecture: all' would mean it was a truly arch-independent
package (documentation, for example).
- hello_1.3-4.diff.gz
The Debianisation diff, as we have now.
- hello_1.3.orig.tar.gz
The original source code, reorganised if necessary into a tarfile
that unpacks into a subdirectory called hello-1.3 or perhaps
hello_1.3.
* Issues:
- Perhaps we need to think again about these hyphens in the context
of source packages, so that we can distribute GNU source tarfiles
unchanged.
- Uploading a new package which only has changes to the diff becomes
trivial. You have to supply a new .dsc and a new .diff.gz, but you
can just name the old original source in the .dsc.
- We need a dpkg-source script to unpack the tarfile and apply the
diff safely (and it can automatically change debian.rules to be
exectutable), but people can do it themselves if they want. Also,
we need a dpkg-source script which runs diff and checks that there
are no differences that diff can't handle (deleted files, retargeted
links, c).
- We need to store the .dsc somewhere when the source is `opened up',
ie, made into a filesystem tree. Either this should be put
somewhere when dpkg-source unpacks an archive, or perhaps it should
have some canonical name in the Debianized source archive
(debian.sourcecontrol perhaps). The dpkg-source script can produce
the Data-MD5sums and Version fields, and check the Source field, so
only Soource, Architecture, Depends and Generates would be needed
here.
* As a reminder, the `one file' format I favour at the moment is an `ar'
archive with members for the control file, diff, original source
tarfile and optionally signature.
Ian.
buzz-fixed - it is essential; how do we make it ?
I'm absolutely convinced that we need a `buzz-fixed' directory, to which Debian-1.1.patchlevel and stable are made to point. I propose that we organise this as follows: * Packages that need to go into buzz-fixed have in the dchanges file `Distribution: unstable buzz-fixed' or perhaps just `Distribution: buzz-fixed' (if the unstable tree has moved on). * A cron job runs daily (well, out of cron.daily or scanpackages, which can be called after upload processing as well) which (a) Checks the buzz-fixes Packages file against the buzz one, and generates a new Packages file which is `what should be in buzz-fixes'. (b) If this is the same as what is in buzz-fixed it stops here. (c) Otherwise, makes appropriate symlinks in buzz-fixed to buzz and buzz-fixes, writes the buzz-fixed Packages file, updates the patchlevel and replaces the Debian-1.1.patchlevel link with a new one. Comments - especially from the members of [EMAIL PROTECTED] - are welcome. Ian.
Bug#3449: netpbm provides no way to make non-RAWBITS file
Package: netpbm Version: 1994.03.01p1-1 I tried to find a way to make the netpbm tools supplied in the package produce a file that was in the ASCII-only format described in pnm(5), rather than the binary format, but this didn't appear to be possible. I think it should be, perhaps as a new program or perhaps as an option to (say) pnmcat. Also, I couldn't find a manpage with a list of the pbm programs with a short description of each - this would have been very helpful. Ian.
Re: kernel-source and kernel-headers packages
Brian Mays writes (Re: kernel-source and kernel-headers packages): Ian Jackson [EMAIL PROTECTED] writes: Can't these be retired ? ... Why not just ship the (debianised, obviously) source to the kernels we ship as .tar.gz and .diff.gz, just like any other binary package ? Here is one thing to consider. The kernel-source .deb file includes processing scripts to keep track of installed versions of the kernel source (when several different versions of the kernel source have been installed) and points the /usr/src/linux symlink to an apropriate kernel source directory. A simple .tar.gz file cannot do this. The /usr/src/linux symlink is no longer necessary for anything very much, and in any case it seems to me that having the most-recently-unpacked thing alway set this link to itself is bad. But really the main problem is that a .deb package is a stunningly bad way of distributing source code - it's exactly the kind of thing that dpkg (and indeed almost any package management scheme for binary packages) will have huge trouble with, because people will always be editing it, compiling it, rm -rf'ing it, c. Ian.
Bug#3450: netpbm should replace/conflict with pbmplus ?
Package: netpbm Version: 1994.03.01p1-1 I got a huge number of file conflicts between pbmplus (10dec91-2) and netpbm, all for the manpages. Either the manpages should have the suffix .1netpbm instead of .1 (though as the binaries are in /usr/bin this is probably unnecessary) or netpbm should Conflict/Replace pbmplus so that pbmplus gets removed (if this is appropriate) or Replace it so that the files get overwritten without warnings (if this is appropriate). Which of the latter two to do depends on whether pbmplus is staying around or not. Ian.
Re: xterm_color with no colors
Mark Eichin writes (Re: xterm_color with no colors): Why does the colour xterm package not set TERM correctly by default ? because I didn't know that xterm-color *existed* as a terminfo entry. The entry is *not* part of the xterm-color package; I have no idea where it comes from. I'll put out a -5 with the utmp patch and the default term setting fixed sometime soon. The xterm-color entry appears to be in ncurses-base, according to my dpkg. You might like to ask the ncurses maintainer when this happened, and add a version-specific dependency. Ian.
Re: Bug#3422: termcap entry too long error
Dale Scheetz writes (Re: Bug#3422: termcap entry too long error): [...] However, it seems to me that if dpkg made some kind of running log entry of it's activities, or could time-stamp it's installations, debugging of these two problems could provide adequate answers to who did what to whom. [...] See - Bug#957 - /usr/doc/dpkg/WISHLIST Ian.
Bug#3989: `w' produces corrupted output
Package: procps Version: 1.01a-1 -chiark:~ w 2:13pm up 17 days, 12:23, 12 users, load average: 0.31, 0.20, 0.14 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT richard ttyp0mojave.elmail.co 9:24am 26.00s 0.65s 0.65s -bash pjb1008 ttyp2ash.eng:0.0 10:00am 12:37 1.50s 1.24s -bash ian ttyp1:0.0 11:22am 2:51m 1:36 0.63s xclock ian ttyp3:0.0 11:22am 2:51m 0.14s 0.14s bash ian ttyp7:0.0 11:23am 1.00s 0.54s 0.25s w matthew ttyp8puffball.atml.co 11:30am 2:43m 0.36s 0.36s bash kat ttypamtcsf.mt.ic.ac.u 12:07pm 1:19m 0.82s 0.51s trn stevettypbtheron.cl.cam.ac 12:31pm 1:27 13.01s 12.80s pine stevettypctheron.cl.cam.ac 12:32pm 0.00s 0.49s 0.22s ftp ftp.mcc.ac. ian ttypd:0.0 2:09pm 11.00s 0.10s 0.09s rlogin localhos ijackson ttypelocalhost 2:09pm 11.00s 0.37s 0.37s /bin/bash root ttypf:0.0 2:09pm 3:30 0.24s 0.24s bash -chiark:~ And, from one of my users: chiark:richard$ w 2:09pm up 17 days, 12:19, 13 users, load average: 0.29, 0.18, 0.14 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT richard ttyp0mojave.elmail.co 9:24am 0.00s 1.08s 0.60s w pjb1008 ttyp2ash.eng:0.0 10:00am 8:38 1.50s 1.24s -bash ian ttyp1:0.0 11:22am 2:47m 1:36 0.61s xclock ian ttyp3:0.0 11:22am 2:47m 0.14s 0.14s bash ian ttyp7:0.0 11:23am 9.00s 0.26s 0.26s bash matthew ttyp8puffball.atml.co 11:30am 2:39m 0.36s 0.36s bash ian ttyp9:0.0 2:09pm 30.00s 0.13s 0.13s trn kat ttypamtcsf.mt.ic.ac.u 12:07pm 1:15m 0.82s 0.51s trn stevettypbtheron.cl.cam.ac 12:31pm 35:58 12.20s 11.99s pine stevettypctheron.cl.cam.ac 12:32pm 1:37m 0.22s 0.22s bash ian ttypd:0.0 2:09pm 22.00s 0.10s 0.09s rlogin localhos ijackson ttypelocalhost 2:09pm 22.00s 0.46s 0.09s mailx root ttypf:0.0 2:09pm 1.00s 0.18s 0.17s bash chiark:richard$ As he says, it's also not clear what units the idle times 8:38 and 35:58 are supposed to be. Ian.
Documentation formats
Increasingly, documentation is in a generic markup format that can be processed into various output formats either by standard tools or ones that come with the package. For example: * GNU Texinfo can be converted to Info, DVI (and hence rather large PostScript) and HTML. * The Linux FAQ comes in plain ASCII, HTML, Info, and PostScript via Lout. * The Linux HOWTOs are done in linuxdoc-sgml, which produces ASCII, HTML, Info and LaTeX (hence DVI and large PostScript). * My new dpkg manuals will be available in plain ASCII, overstruck ASCII, HTML and Postscript (via Lout). * The Perl documentation can be converted to HTML, plain text, manpage source (hence overstruck text and PostScript) and LaTeX (hence DVI and large PostScript). We need to decide which documentation formats we wish to distribute, and how to manage their display. Obviously we can't distribute all of the output formats as that will either make packages too large or produce too many packages. For some of the formats you can process the data `on the fly' as it is viewed; for others (at least TeX, Lout and HTML) this is trickier as the processing or viewing involves dumping the formatted document to a file, or storing some kind of auxiliary data in files while it's being processed. Options for our policy include: 1. Specify one or two particular preferred target formats and distribute those. Leave the source in the source package. So far we have done this with documentation in Texinfo - we leave the .texi files in the source package and distribute only the info files. 2. Distribute the source only and a converter. This has been done with manpages, and with the Perl `pod' documentation. 3. Distribute the source and one target format for people who don't have or want converters. 4. Do something fancy with Lars's documentation viewing stuff. I'm sure Lars will tell us about this. My inclination is to go for 4 with 2 or 3, if that makes sense. Ian.
Emacs per-package startup files
OK, so we've decided to have packages put their Emacs startup stuff in a directory, with one file per package. The directory obviously ought to go in /etc, and the files made conffiles, so that the sysadmin can reconfigure things. /etc/emacs/site-start.d ? Ian.
`experimental' as a Distribution value
I'm shortly going to release experimental versions of dpkg and hello. They'll use the new source package format, which hasn't settled down yet, so they ought to go in project/experimental. Unless someone tells me otherwise I'm going to ship them with `Distribution: experimental' in the .changes file (rather than, for example, marking the files as `byhand' in the Files section). This seems to me to be more orthogonal than the alternative, and it leaves the way open for this to be automated more than it is at the moment. I don't believe that dinstall supports this yet, but as an interim measure it could just treat such uploads as all having files marked `byhand'. Ian.
dpkg 1.3.0, hello 1.3-7: new source package format
I'd like people to take a look at what I've done here. The dpkg 1.3.0
binary package is fine to install and use (and indeed, it fixes a bug
or two), but the whole thing ought not to be moved even into unstable
until we've finalised the new source package format.
The new dpkg contains a bevy of new scripts; the new hello package
should produce the same binary package, but the source is all
rearranged. For a more complex source example you can see dpkg.
Documentation, in the form of the new programmers' and policy manuals,
will be forthcoming very shortly.
Ian.
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Tue, 6 Aug 1996 02:31:52 +0100
Source: dpkg
Binary: dpkg
Architecture: source i386
Version: 1.3.0
Distribution: experimental
Urgency: low
Maintainer: Ian Jackson [EMAIL PROTECTED]
Description:
dpkg - Package maintenance system for Debian Linux
Changes:
dpkg (1.3.0) experimental; urgency=LOW
.
* dpkg can install named pipes.
* dpkg-deb supports directory for destination, generates filename.
* dpkg-{source,gencontrol,genchanges,parsechangelog,buildpackage},
dpkg-distaddfile scripts to support new source package format.
* a.out build no longer supported.
* Changed to new source package format.
Files:
cefed959519825093d3d5f9844fbbf9e 526 base required dpkg_1.3.0.dsc
1289e4578de3eee386770a6653045677 391353 base required dpkg_1.3.0.tar.gz
403586a1dc2ce73c3b60dc38c54e4815 241538 base required dpkg_1.3.0_i386.deb
f9c0d03408eb007a41aa0ad2d17dd85a 236451 byhand -
dpkg_1.3.0_i386.nondebbin.tar.gz
-BEGIN PGP SIGNATURE-
Version: 2.6.2i
iQCVAwUBMgdbNcMWjroj9a3bAQFvowP/Vy3wqOVEo0aSdS19/PRQWXG3sZXEHHES
g6gwReX1Q5S1jfNIbVfOsVK/6Ovj5hZzQu9SKFjuXQEWLZ5dwuPyAFfQXWBPrYmR
HvSoT4iVKJh04ceNeAAve9nju1UySoVcqjhPyEQXEUlpx0L6RS2hFHoX8EwyJVWi
g+0t3b68oWg=
=/ZEv
-END PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Tue, 6 Aug 1996 02:22:38 +0100
Source: hello
Binary: hello
Architecture: source i386
Version: 1.3-7
Distribution: experimental
Urgency: low
Maintainer: Ian Jackson [EMAIL PROTECTED]
Description:
hello - The classic greeting, and a good example
Changes:
hello (1.3-7) experimental; urgency=LOW
.
* Changed to new source packing scheme.
Files:
67d6f1ce34215741d958a3e113ba512e 585 devel optional hello_1.3-7.dsc
1b36dd5413283b0e18f45784e6ee433b 87701 devel optional hello_1.3.orig.tar.gz
8a3125503ca8fadce859786ebd72ddb1 2612 devel optional hello_1.3-7.diff.gz
704d0342835a2a818c221db6b3078ba5 13726 devel optional hello_1.3-7_i386.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.2i
iQCVAwUBMgdbmMMWjroj9a3bAQFywQQAzMdFhorexxHrmrHlHYQF/FtkkpwRN0GV
mKEfVsU7iJUtSUjkDiZROlPGnzOvjUlg0pOBPcs1yInCTRG9M8/1KM+7l0hDsZWv
0XWpgQuHU5ra7c6TtQbLBzr8PSTMPSfPZTJcDyGXPwWoH5VOohC8RzfoS4CFn++A
7UmaLUQgCOI=
=D9yh
-END PGP SIGNATURE-
dpkg-changelog-mode (dpkg-changelog.el)
My upload of dpkg 1.3.0 didn't include the file below. It is an Emacs mode for editing the changelogs that dpkg-parsechangelog understands. Try it (on your own packages or on the changelog from hello 1.3-7) and let me know what you think. When I know where to put the autoload definitions I'll release a dpkg version with this file. I don't propose to use the auto-mode-alist: the file is named simply `changelog' because it is in the `debian' subdirectory of the source tree, and binding that filename to dpkg-changelog-mode would IMO be too obnoxious. Instead people can perhaps use a local variables clause to set the mode. There are facilities in dpkg 1.3.0 for defining a parser for a different changelog format. I put this in because people seemed so hung up on the Emacs format, which I think is dreadful. However, if someone defines a standard way of representing the required information in an Emacs-style changelog and writes the parser for it I'll distribute it. Of course I'd be far happier if there were a (possibly rough) consensus that we should stick to my format so that I can write that into the policy manual, but for the moment I'll just mandate that you have to use a format that the latest dpkg supports (so that people don't need to find your home-grown parser to build your package). Ian. ;; dpkg-changelog.el --- change log maintenance for dpkg-style changelogs ;; Keywords: maint ;; Copyright (C) 1996 Ian Jackson ;; This file is part of dpkg. ;; ;; It is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; ;; dpkg is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with your Debian installation, in /usr/doc/copyright/GPL. ;; If not, write to the Free Software Foundation, 675 Mass Ave, ;; Cambridge, MA 02139, USA. (require 'add-log) (defvar dpkg-changelog-urgencies '((?l.LOW) (?m.MEDIUM) (?h.HIGH)) alist of keystrokes vs. urgency values dpkg-changelog-urgency ^c^u.) (defvar dpkg-changelog-distributions '((?s.stable) (?u.unstable) (?c.contrib) (?n.non-free) (?e.experimental)) alist of keystrokes vs. distribution values for dpkg-changelog-distribution ^c^d.) (defvar dpkg-changelog-mode-map nil Keymap for dpkg changelog major mode.) (if dpkg-changelog-mode-map nil (setq dpkg-changelog-mode-map (make-sparse-keymap)) (define-key dpkg-changelog-mode-map \C-c\C-a 'dpkg-changelog-add-entry) (define-key dpkg-changelog-mode-map \C-c\C-f 'dpkg-changelog-finalise-last-version) (define-key dpkg-changelog-mode-map \C-c\C-c 'dpkg-changelog-finalise-and-save) (define-key dpkg-changelog-mode-map \C-c\C-v 'dpkg-changelog-add-version) (define-key dpkg-changelog-mode-map \C-c\C-d 'dpkg-changelog-distribution) (define-key dpkg-changelog-mode-map \C-c\C-u 'dpkg-changelog-urgency) (define-key dpkg-changelog-mode-map \C-c\C-e 'dpkg-changelog-unfinalise-last-version)) (defun dpkg-changelog-add-entry () Add a new change entry to a dpkg-style changelog. (interactive) (if (eq (dpkg-changelog-finalised-p) t) (error most recent version has been finalised - use ^c^e or ^c^v)) (goto-char (point-min)) (re-search-forward \n --) (backward-char 5) (if (prog1 (looking-at \n) (forward-char 1)) nil (insert \n)) (insert * ) (save-excursion (insert \n))) (defun dpkg-changelog-headervalue (arg re alist) (let (a b v k (lineend (save-excursion (end-of-line) (point (save-excursion (goto-char (point-min)) (re-search-forward re lineend) (setq a (match-beginning 1) b (match-end 1)) (goto-char a) (if arg nil (message (mapconcat (function (lambda (x) (format %c:%s (car x) (cdr x alist )) (while (not v) (setq k (read-char)) (setq v (assoc k alist (delete-region a b) (if arg nil (insert (cdr v (if arg (goto-char a (defun dpkg-changelog-urgency (arg) Without argument, prompt for a key for a new urgency value (using dpkg-changelog-urgencies). With argument, delete the current urgency and position the cursor to type a new one. (interactive P) (dpkg-changelog-headervalue arg \\;[^\n]* urgency=\\(\\sw+\\) dpkg-changelog-urgencies)) (defun dpkg-changelog-distribution (arg) Without argument, prompt for a key for a new distribution value (using dpkg-changelog-distributions). With argument, delete the current distribution and position the cursor to type a new one. (interactive P) (dpkg-changelog-headervalue arg ) \\(.*\\)\\; dpkg-changelog-distributions
Draft manuals
I have finished draft versions of the programmers' and policy manuals. The PostScript conversion isn't working yet, but they are available for your perusal in HTML or plain text (with or without overstrikes). HTML via the Web: http://chiark.chu.cam.ac.uk/~ian/programmer.html/ http://chiark.chu.cam.ac.uk/~ian/policy.html/ Note the trailing / on each URL. ASCII text versions, SGML source and the DTD via anon-ftp: chiark.chu.cam.ac.uk:/users/ian/dpkg-doc/ Your comments would be appreciated; feel free to send patches to the .sgml files if you think it appropriate (but don't send lots of unrelated patches together). PACKAGE MAINTAINERS TAKE NO ACTION. This is NOT an official announcement of the change to the standards. If you want to see what's coming and argue about it (again) please do so though :-). The DTD was once linuxdoc but is no longer. I've ripped out everything that my converters don't support, and added new tags to do the things that I needed. I've called it dpkgdoc. The converters are based on sp (the SGML parser package containing nsgmls) and sgmlspm (the Perl modules for parsing sgmls output) with another Perl glue script for cross-referencing. Ian.
sysv `news' package is unclear
Package: news Priority: extra Section: admin Description: System news tool. (System V) In addition the fact that this description is inadequate (which will have been reported automatically a few weeks ago), IMO the package name is very misleading - it will make people think the package has something to do with USENET. Unless someone objects I shall report this as a bug, requesting that the package be renamed to `sysvnews'. Ian.
Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?
Dirk Eddelbuettel writes (Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?): [Ian Jackson:] Should we move the copyright file (and the examples directory) into the per-package directory in /usr/doc ? Good idea. Can we also recommend/impose to include the Changelog [1] file ? What is the feeling on this ? Since the new source format mandates the existence of the changelog and specifies that it must be in one of a small number (currently 1) of formats I'm inclined to say that we should mandate its inclusion - gzipped. We then end up with two files per package, and it then makes even more sense to move the copyright file. [1] The format could either be free format, or if one is imposed, an emacs function should be provided, otherwise add-change-log-entry is good enough. We all know that Ian hates it, as he hates debian-changes, but it's real easy on the user. Try out the new source format and tools. I think you'll like the degree of automation it provides. It has its own script to produce .changes files. It's also full of hooks and interfaces for you to add to and/or modify its behaviour. Ian.
dpkg 1.3.1: source package tools' documentation improvements
The main new thing here is a manpage for dpkg-source and the related scripts. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Thu, 8 Aug 1996 02:36:04 +0100 Source: dpkg Binary: dpkg Architecture: source i386 Version: 1.3.1 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: dpkg - Package maintenance system for Debian Linux Changes: dpkg (1.3.1) experimental; urgency=LOW . * manpage for dpkg-source et al now available. * dpkg-changelog-mode.el installed in site-lisp, but still no autoload. . * dpkg-source prints correct string for not-understood tar -vvt output. * dpkg-source parsing of tar -vvt output made more robust. . * dpkg-buildpackage prints usage message on usage error. * dpkg-gencontrol can print usage message. * -Tvarlistfile option added to dpkg-source. * Description of -ffileslistfile corrected in dpkg-distaddfile usage. * -mmaintainer synopsis changed in dpkg-genchanges usage. * debian/substvars may now contain blank lines. Files: 94d3772b064bcd1ccb33da2900c5a014 526 base required dpkg_1.3.1.dsc 49a8ccab094534cb207b0826b1847fb6 399324 base required dpkg_1.3.1.tar.gz e8870bf653709d6584e7af6714729e2e 247294 base required dpkg_1.3.1_i386.deb 7dd0863e3b9e761457c62a5be1473a3d 242444 byhand - dpkg_1.3.1_i386.nondebbin.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMglJ4sMWjroj9a3bAQEvRAQAoNqF+Ce8+fkExK9waIYQV9TICmKAMHow SOoUBE0TxjeBE3YE/AfPvKQMAzwTOyUlUjdvQeXdHQxSGPXUVZDGdPmMAVpUesMu BqFwPobeUDA/LpF55n9O9sIONld6JtZS/KQ2c2R+zS0vqLd3FBcYToY1fevGEwe2 u8Kow5KJv2M= =rnb9 -END PGP SIGNATURE-
Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?
Erick Branderhorst writes (Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?): ... No, the /usr/doc/package dir is a dir which normally comes with all stuff in it gzipped and I think we should keep it like that. We can not gzip copyright files (this has been decided/mandated long ago) so I think it isn't good to put an ungezipped file in there. It seems to me that some files being gzipped and some not is a very weak reason for putting them different directories. Furthermore, (a) we could decide to gzip the copyright file if we wanted to and (b) the documentation in /usr/doc is currently only compressed unless it is small (according to both the current guidelines and the new policy manual). Minor argument is that the current approach is space saving. If no documentation comes with package an dir entry needs to be created for its copyright file, when this is in /usr/doc/copyright this will not be required. Using one disk block and one inode per installed package in order to allow the user to find the documentation more easily seems like a good tradeoff to me. I still think that copyright file can/should be autogenerated by the package building process and provide a default part and a free part. Check mailing archives if you want to know more on this. I'm afraid I don't (want to know more). Ian.
Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?
Guy Maor writes (Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?): ... I don't think we should move the copyright file. Most people don't ever need to look at them, so it's simpler if they're out of the way. What about the changelog ? In general I'm not convinced that keeping things `out of the user's way' is a good idea - especially given that the copyright file is the only one that's guaranteed to exist. If we're not careful we'll have the user only looking at the copyright file, having achieved the effect of keeping all the other documentation out of the way :-). Isn't the name `copyright' sufficiently clear that people will avoid reading it when they don't need to ? We should discourage making a symlink from /usr/doc/package to the copyright directory. Maintainers are probably just using the copyright more as a general readme. The copyright file need only contain (surprise) copyright information. I've done this in the new manual. I do, however, think we should move the examples directory. I've always thought the distinction between /usr/doc/package and /usr/doc/examples/package was arbitrary. It usually leads to the obtuse arrangement where the example is in one directory and its accompanying documentation is another. Indeed. I've put this in the new policy manual. Ian.
Draft manual updates PostScript version available
I've made a few minor edits and rearrangements. The PostScript (via Lout) formatting is now working. Updated versions are at: http://chiark.chu.cam.ac.uk/~ian/programmer.html/ http://chiark.chu.cam.ac.uk/~ian/policy.html/ ftp://chiark.chu.cam.ac.uk/users/ian/dpkg-doc/ So, what should I distribute in the dpkg .deb file ? Even the smallest format, the plain text version, is nearly 50Kb compressed. HTML is nearly as small as that. Oh, and is anyone planning to do an sgmlspm package ? This is required to format the documentation, and I'm no Perl expert so I'm wary of doing it myself. Ian.
Re: How do I compare unstable/source to unstable/binary-m68k
Guy Maor writes in private email - I hope he won't mind me posting: On Thu, 1 Aug 1996, Ian Jackson wrote: [EMAIL PROTECTED] writes: I'd like to see where we sit as far as catching up and was wondering if anyone has a nice little script that will compare the source directory to the binary directory and report the differences. I put together a little script to do it, but it's not the greatest... It can't be done at the moment, because the information isn't in the various files. The information isn't in the files, but it's in the filenames. I'm afraid it isn't, because you can't tell just by looking at a .deb file which version of the source it was made from - or even, in some cases, which source package it came from at all. The new source packaging scheme and the tools that go with it put a Source line in the .deb file with the name and the version number if necessary. I think that since at the moment all the primary maintainers are building for i386 you'd be best off to compare binary-i386 with binary-m68k. When we've converted the packages you can do what you want easily. Ian.
Bug#4075: Possible security problem with lrzsz
Package: lrzsz Version: 0.12a-5 I've not heard from the author wrt my query below. I'm filing this bug to make sure that this issue gets checked rather than forgotten. Thank you for your attention. Ian. Mike Neuffer writes (Re: lrzsz ? Re: forwarded message from CERT Bulletin): ... I'm not the author, but lrzsz is almost identical to the normal rzsz implemetation the only difference is that it gives more status information. The diff itself is rather small. --- start of forwarded message (RFC 934 encapsulation) --- In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] To: Debian private list [EMAIL PROTECTED] Subject: lrzsz ? Re: forwarded message from CERT Bulletin CERT write: Topic: Trojan Horse vulnerability via rz program ... All existing versions of the rz program (a program for receiving files over serial lines using the Z-Modem protocol) are equipped with a feature that allows the sender of a file to request the execution of arbitrary commands on the receiver's side. The user using rz does not have any control over this feature. The workaround is to have rz never execute any command, and always pretend a successful execution. The version we distribute is called `lrzsz', and I suspect it is a different version. Nevertheless I'd appreciate it if the author could confirm that the command execution feature is disabled. Ian. --- end --- --- start of forwarded message (RFC 934 encapsulation) --- Article: 124 of comp.security.announce Path: lyra.csx.cam.ac.uk!warwick!usenet.eel.ufl.edu!spool.mu.edu!news.sgi.com!enews.sgi.com!lll-winken.llnl.gov!uwm.edu!math.ohio-state.edu!news.cis.ohio-state.edu!nntp.sei.cmu.edu!news.sei.cmu.edu!cert-advisory Newsgroups: comp.security.announce Organization: CERT(sm) Coordination Center - +1 412-268-7090 Lines: 206 Approved: cert-advisory@cert.org Distribution: world Message-ID: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] NNTP-Posting-Host: why.cert.org Keywords: security CERT Originator: cert-advisory@cert.org Originator: [EMAIL PROTECTED] From: CERT Bulletin cert-advisory@cert.org Subject: CERT Vendor-Initiated Bulletin VB-96.12 - FreeBSD Date: 30 Jul 1996 19:22:18 GMT - -BEGIN PGP SIGNED MESSAGE- = CERT(sm) Vendor-Initiated Bulletin VB-96.12 July 30, 1996 Topic: Trojan Horse vulnerability via rz program Source: FreeBSD, Inc. To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from FreeBSD, Inc. FreeBSD, Inc. urges you to act on this information as soon as possible. FreeBSD, Inc. contact information is included in the forwarded text below; please contact them if you have any questions or need further information. ===FORWARDED TEXT STARTS HERE = FreeBSD-SA-96:17Security Advisory Revised: Tue Jul 16 21:44:54 PDT 1996 FreeBSD, Inc. Topic: Trojan Horse vulnerability via rz program Category: ports Module: rzsz Announced: 1996-07-16 Affects:All FreeBSD ports collections released before 2.1.5-RELEASE Corrected: ports collection as of 1996-07-06 Source: rzsz shareware package FreeBSD only: no Patches:ftp://freebsd.org/pub/CERT/patches/SA-96:17/ = I. Background All existing versions of the rz program (a program for receiving files over serial lines using the Z-Modem protocol) are equipped with a feature that allows the sender of a file to request the execution of arbitrary commands on the receiver's side. The user using rz does not have any control over this feature. The workaround is to have rz never execute any command, and always pretend a successful execution. All FreeBSD users are encouraged to use the workaround provided. Since the intent of the Z-Modem protocol is to provide a reliable connection between systems of a vastly different architecture, the execution of local commands at request of the sending side cannot even be considered a useful feature at all. II. Problem Description The Z-Modem protocol specifies a mechanism which allows the transmitter of a file to execute an arbitrary command string as part of the file transfer. This is typically used to rename files or eliminate temporary files. A malicious trusted sender could send down a command that could damage a user's environment. III. Impact The rzsz package is an optional port that made be installed on some FreeBSD systems. This program is not installed by default. Systems without this program are
Bug#4073: make pattern rules delete intermediate files
Package: make Version: 3.74-11 Given the Makefile below in an empty directory: chiark:d make clean rm -f t.* u.* chiark:d make echo bar t.bar echo foo t.foo echo wombat u.wombat echo spong u.spong rm t.bar chiark:d We see that the intermediate file used for the pattern rules (%.bar) is removed by make, and that this doesn't happen if we use suffix rules. This is silly. Consider the dependency graph (a -- b means a is required to generate b, and b depends on a): a -- b --+-- d c ' where b and d are automatically generated. Now if you start with a clean directory and say `make d' make generates b from a, and then d from b and c. However, it then deletes b again. If you edit c and want to rebuild it has to regenerate b, and it ends up doing this every time. This defeats the purpose of using make, which is supposed to avoid rebuilding files unnecessarily. This doesn't appear to happen if the rules involved are ordinary targets, only if they're pattern targets. I can't find any documentation about this `feature', and there doesn't appear to be a way to turn it off. Ian. PS: You may need to put this Makefile through `unexpand' to put the tabs back. It has them now when I send the message, but tabs are notorious for being mangled. .SUFFIXES: .SUFFIXES: .spong .wibble .wombat all:t.foo u.spong %.foo: %.bar echo foo $@ %.bar: echo bar $@ .spong.wibble: echo wibble $@ .wombat.spong: echo spong $@ u.wombat: echo wombat $@ clean: rm -f t.* u.*
Bug#4074: problems with 1.1 release
Package: dpkg Version: 1.3.1 Scott Barker writes (Re: problems with 1.1 release): ... ok. Although, I beg to differ about the *.conffiles: ls /var/lib/dpkg/info/*.conffiles /var/lib/dpkg/info/adduser.conffiles /var/lib/dpkg/info/at.conffiles /var/lib/dpkg/info/base.conffiles [etc] Oops, this is a bug. I'll fix it some time (it's just some wasted space - there are no real problems with it). Ian.
Bug#3838: GCC should depend on CPP, not conflict with it
David Engel writes (Re: Bug#3838: GCC should depend on CPP, not conflict with it): Ian Jackson writes: ... Hmm. Why is it necessary for gcc to know which version of cpp is available, or for it to have exactly the right one ? Would you want the front-end driver (gcc) to use different versions of cpp and cc1/cc1plus? Forgive my naivete', but I don't see why it should matter. Ian.
Bug#4078: lynx should be in `contrib'
Package: lyx, ftp.debian.org Version: 0.9.28-1 This package depends on a non-free package (xforms). It should be in contrib, not in the distribution proper. Ian.
Bug#4079: compress-package should be in `contrib'
Package: compress-package, ftp.debian.org Version: 1.0.1-1 This package is only an installer for a non-free piece of software. It should be in contrib, not in the distribution proper. Ian.
Documentation formats
I've just added the subsection below to the draft policy manual. Bruce, tell me if you want me to say something different. I'd like to come up with some rather more formal way of distributing our different documentation formats. Perhaps we should create a new subdirectory of the FTP site for packages' PostScript documentation and upload it separately. Alternatively we could recommend that if a package can produce documentation in n formats it should put the HTML in with the package itself (if it doesn't warrant a separate package) but put the other n-1 together in a separate package which uses some canonical naming scheme. Eg, dpkg - contains the programs and the HTML documentation dpkg-docxf - contains the documentation in ps, plain text c or texinfo- contains the Texinfo formatter itself texinfo-doc- contains the documentation run through texi2html texinfo-docxf - contains the docs in /usr/info, and as dvi If we do this we should probably say that if a package produces dvi as its native format we should ship dvi and not ps. Ian. sect1Preferred documentation formats The unification of Debian documentation is being carried out via HTML. p If your package comes with extensive documentation in a markup format that can be converted to various other formats you should if possible ship HTML versions in the binary package, in the directory tt/usr/doc/var/package// or its subdirectories. p Other formats such as PostScript may be provided at your option.
Bug#4088: ghostview does not put filename in window title
. */
psfree(olddoc);
@@ -328,6 +329,28 @@
titlemenu = build_label_menu(titlebutton, title, label, bitmap);
}
+if (nameprop.value) {
+ XFree(nameprop.value);
+ nameprop.value = 0;
+}
+if (app_res.window_title) {
+ if (doc doc-title) {
+ title = doc-title;
+ } else {
+ title = filename;
+ }
+ versionfilename = XtMalloc(strlen(version)+3+strlen(title)+1);
+ strcpy(versionfilename, version);
+ strcat(versionfilename, - );
+ strcat(versionfilename, title);
+ XStringListToTextProperty(versionfilename, 1, nameprop);
+ XtFree(versionfilename);
+} else {
+ XStringListToTextProperty(version, 1, nameprop);
+}
+if (nameprop.value XtIsRealized(toplevel)) {
+XSetWMName(XtDisplay(toplevel), XtWindow(toplevel), nameprop);
+}
if (app_res.show_date) {
if (doc doc-date) {
label = doc-date;
--
Ian Jackson, at home. [EMAIL PROTECTED] + 44 1223 3 31579
General: [EMAIL PROTECTED]Permanent: [EMAIL PROTECTED]
Churchill College, Cambridge, CB3 0DS. http://www.cl.cam.ac.uk/users/iwj10/
Re: dpkg-changelog-mode (dpkg-changelog.el)
Michael Meskes writes (Re: dpkg-changelog-mode (dpkg-changelog.el)): Do we have an official look the changelog has to have? If so how should it look? I won't be able to test your emacs style since I don't use emacs. Yes, we do. An example (from dpkg) is below. This is documented both by example in hello and dpkg and by specification in the new manual. Ian. dpkg (1.3.1) experimental; urgency=LOW * manpage for dpkg-source et al now available. * dpkg-changelog-mode.el installed in site-lisp, but still no autoload. * dpkg-source prints correct string for not-understood tar -vvt output. * dpkg-source parsing of tar -vvt output made more robust. * dpkg-buildpackage prints usage message on usage error. * dpkg-gencontrol can print usage message. * -Tvarlistfile option added to dpkg-source. * Description of -ffileslistfile corrected in dpkg-distaddfile usage. * -mmaintainer synopsis changed in dpkg-genchanges usage. * debian/substvars may now contain blank lines. -- Ian Jackson [EMAIL PROTECTED] Thu, 8 Aug 1996 02:36:04 +0100
Caldera's lawsuit against Microsoft
I should think that you've all heard about this by now - if not go and look at comp.os.linux.announce. I'm just posting here on what's really an irrelevant topic to say that I think it's a very good thing that someone is challenging Microsoft. I mailed Lyle Ball at Caldera to tell him so, and he thanked me for my support and said: Please be vocal about your opinions on this case, especially on the forums. So, here I am in my favourite forum :-). If you want to discuss this somewhere here probably isn't it. Ian.
Re: Alphas and libc dependencies
Miquel van Smoorenburg writes (Re: Alphas and libc dependencies): You (Ian Jackson) wrote: ... 2a. Give the package containing our version of glibc version 0 the name libc5. 2b. Implement version numbers for virtual packages so that we can use one here. I think 2b should be done; [...] if this would work: Provides: libc5_5.2.18-8, ldso_ 1.7.14-4, timezone_7.48-3, libdb1_1.85.2-8, libgdbm1_1.7.3-11 it would solve a huge problem. The problem is that this is quite a significant amount of work, and I don't really have time to deal with it now. (Incidentally, the syntax would be `Provides: libc5 (5.2.18-8), ldso (1.7.14-4)' c.) ... Would it be very hard to put this in dpkg? Oh and would you like to have the Alpha patches for dpkg first so you can integrate them into the normal version (would make it easier for me). Certainly you should send me your patches. IME architecture patches fall into two categories: bug fixes where I made a mistake (which I'll fix straight away if I can, for example by using your supplied patch) and workarounds for architecture-specific braindamage. I've had some problems with the latter and m68k and ELF, and I have to say that I'm very reluctant to put in `workaround' patches. You have been warned :-). Ian.
Re: fileutils can now replace perforate...
Mark Eichin writes (Re: fileutils can now replace perforate...): [Ian Jackson:] But --sparse=auto is impossible to implement correctly on many systems, and filesystem-dependent on others ! Depends on what you mean by sparse... the trick is that you can use stat() to determine if the file has *any* holes. No, that's precisely what I'm claiming *can't* be done, because of indirect blocks amongst other things. IMO cp should either always produce sparse files by default or never do so by default, not some half-way house that guesses and will get it wrong sometimes. Ian.
Re: Alphas and libc dependencies
Miquel van Smoorenburg writes (Re: Alphas and libc dependencies): ... In addition to my last message, here is an alternative I've just though of. Why don't we just provide dummy (eg empty) libc5, libdb1 etc packages, and let libc6 depend on them. Then libc5 etc _will_ be installed.. I think that's what I'll do until Ian has implemented version numbers for virtual packages (if that's a reasonable solution that is). Well, it's not ideal - in particular, it means that you can deinstall libc6 when you clearly ought not to. How about doing it the other way around - having an empty libc5 package which depends on libc6 ? This is obviously a bit of a nasty hack, but it will have the right effect. Ian.
Re: Emacs per-package startup files
[EMAIL PROTECTED] writes (Re: Emacs per-package startup files): Umm, /usr/lib/emacs/site-lisp/ is already there, and already the right place for this sort of thing. Next question? Err, I don't think so. Files in /usr/lib/emacs/site-lisp aren't loaded automatically (and shouldn't be). As for ordering: use require, and then safe-append a section to /etc/site-start.el, JUST LIKE EVERYTHING ALREADY DOES... we don't need a new mechanism here, just some common simple automation of the one that vm, w3, gnats, and others already use... Respectfully, I disagree. Experience with /usr/info/dir, inetd.conf, and indeed with site-start.el (/etc/site-start.el vs. site-lisp/site-start.el and symlinks, c) has taught us, I feel, that it is a bad thing to have many different packages all dynamically update the same file just to add and remove their own little bits from it. Contrast this with /etc/rc?.d and /etc/rc.boot, where there has been little unfortunate interaction. There's the question of how to distinguish changes made to the shared file by the sysadmin from those made by package maintainer scripts. This is much easier if each package's bit is in a separate file - dpkg's conffiles mechanism can take care of it. There's also the question of having a standard tool. Obviously it would be good to have a standard tool for this kind of thing (a la install-mime and the rest). However, the more you do this the more of these little install-foo scripts you have, and the more stuff you drag in when you try to install the package. For example, supposing Emacs were to provide a script to add things automatically I couldn't use it, because dpkg can't depend on Emacs. The script would have to end up in dpkg itself. So, all in all, I think it would be better to have an arrangement where all the bits that packages would want to put in the site-start are installed as conffiles in a directory, and arrange that the real site-start runs every file in the directory a la run-parts. As for ordering: the entries in site-start aren't supposed to require much ordering. After all, they're autoload definitions and the like. I think a sequence numbering scheme like that for the other package-put-a-file-in-here directories would be quite adequate. Now Emacs is your (Mark Eichin's) package, so you get to decide how things are to be done. I still hope though that I (and others who may agree with me) can persuade you that these arguments have merit, and that it would be better and simpler in the long run if we started making this not particularly arduous transition. Either way I'd appreciate it if, when this discussion is concluded, you could send me some text for the new policy manual about how elisp should be managed. Thanks, Ian.
Re: Bug#3984: NIS writes error message to STDERR
Miquel van Smoorenburg writes (Bug#3984: NIS writes error message to STDERR): ... This is a bug in the library; the library routines print this (they shouldn't ofcourse). Heeemmm can anybody tell me how to redirect a bug report to another package, libc5 in particular? Yes. [EMAIL PROTECTED]' can. As can http://www.cl.cam.ac.uk/users/iwj10/debian-bugs/. Or ftp://ftp.debian.org/debian/doc/bug-*.txt. I can too, but I think you should RTFM. Ian.
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): ... On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). Sorry I'm coming into this so late (just over a week, in fact), but I think this is a daft idea. Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. I think the `editor' virtual package should be scrapped. Ian.
Re: Name clash in prospective package
Lars Wirzenius writes (Re: Name clash in prospective package ): ... For instance, there's no guarantee that /usr/local/lib exists, or that the admin wants it to exist, or that it won't cause any trouble if it does exist. I can't think of anything that would break, but admins are allowed to do funny things in /usr/local. The problem with this strict approach is that we want (for obvious reasons) our tools to search local directories too when looking for commands, Perl modules, lisp files or whatever. Therefore we can't avoid making some assumptions about what's in /usr/local. The point of not putting things in /usr/local isn't, as I see it, so that the sysadmin can put a baroque thing there and have everything work - it won't - but so that they can put their own software there (installed well or badly) without fear of it being destroyed by the packaging system. ... I quite agree that it should be easy to set up such complex things [like directory structures c in /usr/local], but not without asking. I don't think we need to bother the user with one more question, if we provide a way for an expert to have us leave /usr/local alone. I propose the following resolution: * A policy that packages should include in their .deb files empty directories for path-searched directories. Files are not allowed, and packages aren't allowed to touch /usr/local at all in their maintainer scripts. * When dpkg has the `ignore files matching pattern' option (this will be read from a configuration file) you'll be able to stop it installing things in /usr/local at all. I'm afraid this will be a while coming, but in principle it's not too hard. Ian.
Bug#3991: dselect has confusing and bizarre interface
Daniel Quinlan writes (Bug#3991: dselect has confusing and bizarre interface): [ complaints about dselect's user interface ] I am merging this with Bug#1037. Offers of assistance are welcome. Ian.
Debian, Linux, the FSSTND, the FHS and BSD
(Note: this message is crossposted between two mailing lists - you should probably follow up on only one.) What used to be the FSSTND group has changed composition somewhat, and now includes a number of people from the BSD world. It set itself the goal of producing a joint filesystem layout standard, named the FHS. I argued against many of the changes that were proposed, on the grounds such as the disruption that would be caused to the Linux community by moving things or the fact as I saw it that the FSSTND's arrangements were cleaner and that we should not compromise, moving things to messier locations, because BSD had done it that way. I lost this argument, chiefly through a combination of poor politics on my part and the fact that there were more people who seemed willing to make major sacrifices for compatibility with BSD. The latest draft FHS, which they may well publish as it stands, makes the following changes with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * A new directory /usr/libexec is created to hold command binaries used only internally by programs - these are to be moved from /usr/lib and in some cases /usr/sbin. Oddly there is no corresponding /libexec directory. The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. I have spent an awful lot of time and energy on the FSSTND mailing list, and I do not have any left with which to further persue this matter there in the face of the very considerable amount of bad feeling which exists. It pains me greatly to say this, given my emotional investment in the work of the FSSTND, but: if the FHS draft is promulgated as it stands I shall not support its adoption by the Debian project. It looks like we (Debian) are going to need /opt, and possibly /usr/share. We can take those parts if we need them. I'm posting this message so that: (a) The rest of the Debian Project can decide what they want to do. If the consensus is that they wish to follow the new standard then I shall be unhappy, of course. I don't know what my reaction would be in terms, for example, of my authorship of dpkg and of the Debian Project policy manual. Disillusionment, I suppose. (b) The newly-renamed FHS group can reconsider - though I doubt that they will. They'll see this as an attempt by me to blackmail them. For the Debian people: the latest draft can be found on tsx-11.mit.edu in /pub/linux/docs/linux-standards/private/fsstnd/. Ian. [1] When the original FSSTND was created I argued in favour of /libexec and /usr/libexec, but lost that debate. I'm less convinced now than I was then, but my main reason for opposing it now is that it is too late to change.
Re: epoch?? how to make squid-1.0.5 squid-1.0beta16
Craig Sanders writes (epoch?? how to make squid-1.0.5 squid-1.0beta16): ... Was epoch implemented? How do I use it? Yes. See the draft programmers' manual. Ian.
Re: Replaces: and virtual packages?
Yves Arrouye writes (Replaces: and virtual packages?): I thought having a package with Provides: compress Replaces: compress would be like Provides: compress Conflicts: compress except that the conflict will not appear and I hoped that when the package was installed any previous package providing compress would be removed first. I think you want: Conflicts: compress Replaces: compress Provides: compress Ian.
Re: Is it okay to download orig source once only?
Yves Arrouye writes (Is it okay to download orig source once only?): ... I propose that we upload once somepackage_release.tar.gz which unpacks to somepackage-release.orig/ and then further uploads would be somepackage_release-deb.diff.gz somepackage_release-deb_arch.deb Would that be okay? Not at the moment, no, because the .tar.gz is the debianised source. However with the new source package format this is possible in principle, though in practice there are a few technical issues with dpkg-source to be sorted out. Ian.
Re: gcc and binutils
Bernd Eckenfels writes (gcc and binutils): ist it possile that on a fresh new install gcc is installed before binutils is installed, and therefore fail to configure? If I run configure afterwards everything is fine. Will dpkg install a package first if it sees that other ones depend on it? Err, I don't quite understand the question. The answer to your first sentence is `no, it shouldn't be possible'. See the draft programmers' manual for details of exactly how things happen. Ian.
Re: Draft manuals
Raul Miller writes (Re: Draft manuals): Some thought about qmail should occur [in the section on mail processing]. qmail doesn't use a mail spool directory for security reasons, mail boxes are in the user's home directory by default. And, of course, there's the maildir format for people wanting a very robust system. I've seen mention on debian-devel of making movemail aware of maildir. I suspect that this is the right thing to do. qmail's author has taken a deliberate choice to be incompatible with things, and this means that we can either: * mandate that everything support what qmail does * live with not everything working when you use qmail. What precisely do you think I should put in the policy manual on this subject ? I'm loath to mandate that every program support qmail's maildir format. Perhaps the qmail package should come with a local delivery agent that can do delivery into /var/spool/mail ? It only has to be setgid mail, not setuid root. That requirement would be the effect of the policy requirements as they're written atm. Ian.
Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?
Erick Branderhorst writes (Re: /usr/doc/copyright/package -
/usr/doc/package/copyright ?):
...
But a /usr/doc/copyright dir should remain. The only contents allowed in
there would be generic copyright messages like GPL LGPL BSD and so on.
Putting these generic files in /usr/doc/base/{GPL,LGPL,BSD} is not wise
IMHO. Additionally because translated version of the above generic
copyright messages are on the net and it might be usefull to put these
translations there as well. This specific group of files justify to have a
directory for them selves IMHO. I don't mind that these are gzipped.
That seems reasonable to me. We should leave a README there pointing
people to /usr/doc/package/copyright.
Ian.
Bug#3838: GCC should depend on CPP, not conflict with it
David Engel writes (Re: Bug#3838: GCC should depend on CPP, not conflict with it): ... Because they're designed to work together. That's why the FSF includes cpp with gcc instead of packaging it separately. This doesn't much sense to me, at least not without more detail. Why do gcc and cpp need to know each other's particular versions ? There are lots of other things that are designed to work together where a bit of version slippage doesn't matter. Ian.
sgmlspm 1.03ii-1: initial experimental release
This is the Perl5 module that I've been using to support my dpkg manual processing backends. Because it's in the new source format and refers to an as-yet-nonexistent virtual package I'm sending it into experimental. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 10 Aug 1996 01:47:30 +0100 Source: sgmlspm Binary: sgmlspm Architecture: source all Version: 1.03ii-1 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: sgmlspm- Perl modules for processing SGML parser output Changes: sgmlspm (1.03ii-1) experimental; urgency=LOW . * Initial Debian release. Files: 470ebffa5f64d0dbd2e8a68e2ae2bdbf 607 text optional sgmlspm_1.03ii-1.dsc 6813acffaa1d2798908ce28725604a9c 92641 text optional sgmlspm_1.03ii.orig.tar.gz 6185b1db8fcf734dc19f34d1293a8d32 2250 text optional sgmlspm_1.03ii-1.diff.gz 5219d462920b220fe2722bfefe11628c 50830 text optional sgmlspm_1.03ii-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgvcRMMWjroj9a3bAQHlPQQA8F1h+XsuKtCDIoEpnkvA1sfxrA0xbxZ6 jySHyKiy5Y28DFXKO0J9jWf/PhoNm0G8CGq3vGGG4tgxGPBc9ShgWbmhwtMnT0oP osuhGO5B/HKgfhnB0RnWj96TiZK0Oepe3vqSFLBhdk2W7HSschI+TiWUvQPUhY6u 1s49DUE6tdM= =d3fB -END PGP SIGNATURE-
Re: Emacs per-package startup files
Mark Eichin writes (Re: Emacs per-package startup files): ... [it would make it easier to fix the /etc/passwd problem that mhpower mentioned], but in those cases we can't really change the database because of existing use, whereas with emacs we are free to do that.) Right, that was my line of thought exactly. ... Hmm. As for dpkg needing install-elisp, I'm not quite sure I buy that, because it would seem to argue that *any* install-* should be included in dpkg. Then again, there is only install-info which *is* in dpkg, and install-mime which is in mime-support which has it's own justification. There aren't any others... If anyone writes others I'll be happy to include them in dpkg, provided that they're GPL'd. ... So, do these files go in /var/lib/emacs, /etc/emacs, or /usr/lib/emacs/site-lisp, and why? I can set it up and send changes to the emacs package maintainers this weekend if that gets worked out... It needs to be in /etc, and the files must be conffiles, so that sysadmins can edit them and so forth. I suggested /etc/emacs/site-start.d because we already have one Emacs /etc file and /etc is already full of stuff. I guess the only thing unresolved is what directory to use, and what the little bit of elisp should look like that scans the directory. How about making /usr/lib/emacs/site-start.el a file rather than a symlink, and having it load /etc/emacs/site-start.el and run /etc/emacs/site-start.d. I'll look at the text explaining rc.d numbering to see what makes sense for that. (I guess in theory we need the ordering, but in practice, with autoload, do we need ordering here at all? certainly none of the existing packages need it. But I suppose picking an order at least makes debugging easier...) If you just sort the filenames before you run them you'll get the ordering for free, and if we say that people who don't know what number to use or don't think they have ordering constraints use 50 then if we do decide we want something loaded early we can do it. Ian.
Re: CC's on this mailing list
Miquel van Smoorenburg writes (Re: CC's on this mailing list): ... I've noticed on some other lists that everything that is posted on the list has From: set to the original sender, Reply-To: to the list address and Cc: deleted. This is actually very nice. Would it be hard (or just a bad idea) to put this in the debian list server? This makes it hard in some mailers to reply to just the poster. Ian.
Releases other than by the package maintainer
There are a couple of circumstances when a new version of a package needs to be released by someone other than the usual maintainer: * Architecture-specific patches which need to be integrated. * Maintainer is away or can't do it for some other reason. * Urgent security and other fixes. I propose that we should mandate: (a) a broad description of when you should and when you shouldn't do this, and how not to tread on the usual maintainer's toes. (b) that the non-usual-maintainer releases should use a particular revision format: eg, hello-1.3-8 would become hello-1.3-8.1. Ian.
Conversion procedure for new source packages DRAFT
This is my first draft of a quick document saying how to convert an
old to a new source package.
DO NOT DO ANYTHING YET except read this and suggest amendments.
Ian.
* Download the original source code from wherever it can be found and
do any rearrangement required to make it look like the original tree
of the Debian source. Put it in package-upstream-version.orig/.
* Rename all files debian.* to debian/*. There may be some exceptions
to this, but this is a good start.
* Edit the debian/changelog - create or rename it if necessary. Add a
new revision to the top with the appropriate details.
* Edit/create debian/control:
+ Remove the Version field. If it is generated unusually (not equal
to the source version) you must use the -v option to
dpkg-gencontrol (see below). Section, Priority, Maintainer go
above the line, most of the rest below.
+ Reorder the fields and add a blank line at an appropriate point,
separating the source package fields from the binary package
fields.
+ Add the Source field.
+ Add the Standards-Version field.
+ Change the Architecture field for each package to `any', `all' or
whatever. If there isn't an Architecture field add one.
+ If any other seddery or things used to happen to make the binary
control files use dpkg-gencontrol's variable substitution features
to achieve the same effect. Use debian/substvars if you need to
put unusally-generated information (apart from details of .deb
files) in the .changes file too.
* Edit the debian/rules:
+ Remove the source and diff and any changes and dist targets. These
things now happen in a package-independent way and are not done by
debian/rules.
+ Change the binary target to use dpkg-gencontrol to make the package
control file(s).
+ Change occurrences of debian-tmp to debian/tmp.
+ Change occurrences of debian.{post,pre}{inst,rm} to debian/*.
+ Remove the version number make variable if there is one.
* Check that the debian/README is really the copyright file, and if so
rename it to debian/copyright and edit debian/rules accordingly. If
it isn't then find debian/copyright and decide what to do with the
README.
* Check for various other anachronisms:
+ Remove any Package_Revision, Package-Revision or Revision fields.
+ Rename Optional to Suggests, Recommended to Recommends.
+ Change /usr/doc/examples/package to /usr/doc/package/examples
and /usr/doc/copyright/package to /usr/doc/package/copyright.
* Look everything over.
* Do a test build using dpkg-buildpackage -ur -uc -rwhatever. Check
the permissions and locations of the results, and that the source
build happened OK. Test install the binary package(s) and test
extract the source package(s).
* Sign the release: either re-run dpkg-buildpackage (this will rebuild
the package entirely), or PGP-sign the .dsc, rebuild the .changes
using dpkg-genchanges, and then PGP-sign the .changes.
--
Ian Jackson, at home. [EMAIL PROTECTED] + 44 1223 3 31579
General: [EMAIL PROTECTED]Permanent: [EMAIL PROTECTED]
Churchill College, Cambridge, CB3 0DS. http://www.cl.cam.ac.uk/users/iwj10/
Re: New package standards - LAST CALL
Miquel van Smoorenburg writes (Re: New package standards - LAST CALL): ... I also think that when you make the new source package official, we should warn all maintainers of the base packages and ask them to convert their packages to the new standard. If they don't react in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Yes. If a few people do a lot of packages it's probably quicker and less error-prone, anyway, then having the maintainers do it themselves. On the other hand having the maintainers do it themselves will get them to learn the ropes ... ... Well, one other idea. Since the original source and the patch are kept in the archive, would it be possible to look for an additional architecture dependant patch? [...] No. Any architecture dependencies should be avoided; if they can't they should be dealt with at build-time in the package itself, rather than by making several versions of the package. [..] It would be a tremendous advantage when porting to a new architecture - the porter need only supply the extra patch to the debian archive and it will just work. Also, the patch will be in a public place so that the original maintainer can integrate the patch in the next version of the package. The porter should make an architecture-independent patch (ie, one that will work on any architecture) and then either: (a) add `.1' to the Debian revision and release a new source package with their binaries - they should send the patch to the original maintainer for inclusion, too; or (a) send the patch to the main maintainer (or to [EMAIL PROTECTED]) and wait for it to be included. Ian.
Re: Name clash in prospective package
Lars Wirzenius writes (Re: Name clash in prospective package ): Ian Jackson: The point of not putting things in /usr/local isn't, as I see it, so Well, I'm not in full agreement, but it's not important enough. Fair enough. I propose the following resolution: I can live with the what you propose. Good. I've added the section below. Ian. sect1tt/usr/local/ - for the use of the system administrator p As mandated by the FSSTND no package should place any files in tt/usr/local/, either by putting them in the filesystem archive to be unpacked by prgn/dpkg/ or by manipulating them in their maintainer scripts. p Every package that searches a number of directories or files for something (for example, looking for shared libraries in tt/lib/ or tt/usr/lib/) should search an appropriate directory in tt/usr/local/ too. p In order that the system administrator may know where to place additional files a package should create an empty directory in the appropriate place in tt/usr/local/ by supplying it in the filesystem archive for unpacking by prgn/dpkg/. The tt/usr/local/ directory itself and all the subdirectories created by the package should have permissions 2775 (group-writeable and set-group-id) and be owned by tt/root.staff/. p In the future it will be possible to tell prgn/dpkg/ not to unpack files matching certain patterns, so that system administrators who do not wish these directories in tt/usr/local/ do not need to have them.
Re: Qmail, smail and sendmail
Yves Arrouye writes (Re: Qmail, smail and sendmail): ... That's what I do. I even run sendmail -bi if newaliases is not found. But I wanted to be sure that all mail packages do provide the same user way of defining aliases, even if they manage them differently after that. I'll specify in the mail processing section of the polcy manual: tt/etc/aliases/ is the source file for the system mail aliases (e.g. postmaster, usenet, etc.) - it is the one which the sysadmin and postinst scripts may edit. After tt/etc/aliases/ is edited the program or human editing it must call prgn/newaliases/. All MTA packages should come with a prgn/newaliases/ program, even if it does nothing, but older MTA packages do not do this so programs should not fail if prgn/newaliases/ cannot be found. p Ian.
Re: CC's on this mailing list
Yves Arrouye writes (CC's on this mailing list): Ian Jackson writes: I'm considering adding a paragraph to the policy manual telling people not to CC each other when replying to messages on debian-devel. Is it the consensus of the list that this would be a good idea ? It would be nice also to not have long messages fully quoted :-( Right, this is going into the policy manual. Ian.
Re: Pb: gdb cannot read core from 2.0.8 (is it a gdb or kernel problem)?
Yves Arrouye writes (Re: Pb: gdb cannot read core from 2.0.8 (is it a gdb or kernel problem)?): ... But the message is really misleading... It would ne nice if Gdb checked wether the prog arg was a core first, and in this case tell that's the case and remind usage. (Not that I ask that it does that: I should have read the manual page, of course.) You might also see my bug report, #3515. Ian.
Bug#4093: start-stop-daemon fails to kill process
Yves Arrouye writes (Bug#4093: start-stop-daemon fails to kill process): Maybe should it kill the process whose pid is in the pidfile, even if it does not think the executable is running? Here is an example of the problem: marin66# /etc/init.d/apache stop no /usr/sbin/apache found; none killed. marin67# cat /var/run/apache/apache.pid 12707 marin68# ps -ax|grep 12707 12707 ? S0:00 /usr/sbin/apache 20378 p9 S0:00 grep 12707 Are you using a new apache package ? On my system apache installs itself as /usr/sbin/apache-httpd. In any case, could you check to see what ls -ali /proc/12707/exe ls -aliL /proc/12707/exe shows and what ls -ali /usr/sbin/apache shows ? Thanks, Ian.
debiandoc-sgml: SGML-based formatting for Debian/dpkg manuals
(NB: This message is crossposted. Mind your followups.) I felt like linuxdoc-sgml was unsuitable for me because: * It has serious problems with metacharacter handling/escaping. * The DTD doesn't express what was supported by the backends, and is generally full of leftover gunk. * The formatting of certain constructs - especially cross-references and examples - by several of the backends is poor. * It doesn't have all the features I wanted. * It has features I don't want and don't want to bother maintaining. * Its backends generate their output through too many or IMO the wrong intermediate stages (eg, plain text via groff or PostScript via LaTeX). So I wrote this. It's small but it does what it claims to do - translate documents in its DTD into HTML, plain text (overstruck or not) and PostScript (via Lout). Info is not supported at the moment. I've marked it for placement in project/experimental on the Debian archive because it's in the new Debian source package format which hasn't been agreed on yet, not because it's particularly unstable. (Non-Debian users can just untar and build it.) You need `sp' (aka nsgmls) as that's the SGML parser it expects, and SGMLsp (the Perl modules for SGML backends) and Perl5 of course. It has one dependency on linuxdoc-sgml, due to the file /usr/lib/linuxdoc-sgml/rep/latin1/general (which is a list of character entities). There is no documentation for the formatter itself yet, but the DTD contains only things that are supported by the backends and should be fairly clear. I'll write a manual for it when I have a free hour or two. The Debian change information for the package is below. It should appear in project/experimental on the Debian sites shortly. I'm unlikely to be able to help with requests to add features to it, because I'm very busy. However, if you do something sensible to the DTD _and_ support it in _all_ the backends I might look favourably on a patch. Discussing it somewhere if you plan to do this would probably be a good idea. On the linuxdoc-sgml list, perhaps, unless people will mind ? Because the DTD is so small - 87 lines - I've included that too. Ian. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 10 Aug 1996 22:01:38 +0100 Source: debiandoc-sgml Binary: debiandoc-sgml Architecture: source all Version: 1.0 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: debiandoc-sgml - Documentation formatting for Debian manuals Changes: debiandoc-sgml (1.0) experimental; urgency=LOW . * Initial release. Files: 734bc16c3554423a36972a2a3f2b5413 551 text optional debiandoc-sgml_1.0.dsc 150663201886f8433e59f7edd537e44c 23090 text optional debiandoc-sgml_1.0.tar.gz 19e72e5820a609a20499895b1f7943c5 12830 text optional debiandoc-sgml_1.0_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgz+TcMWjroj9a3bAQHk6wQAwySiTOJPoBCgRBha9Hwr2yeIJORIKRBJ 8BhjlZ7DaJdOL9qtZHC+36p/wfzkYb+Me+O5ra6eRXtrQBEm7NXwDrVDqZ+Eqx47 uUsnt4CjhVHNLZBJwAKS4PvoDaY4wxLBmfFq22d6hrfcxSBHyxHNG0K0CcHjDFbr bKTubyoYyE8= =lIe3 -END PGP SIGNATURE- !-- debiandoc.dtd Copyright 1996 Ian Jackson This is free software. You may distribute it under the terms of the GNU General Public Licence, version 2 or at your option any later version. This DTD was inspired by linuxdoc.dtd which was based on QWERTZ. Contributors to linuxdoc.dtd include Matt Welsh, Greg Hankins, Eric Raymond, Marc Baudoin, Tristan Debeaupuis and Tom Gordon. -- !element book - - (titlepag, toc?, chapt+) !element debiandoc o o (book) !entity % emph em|var|prgn|tt|qref !entity % xref ref|manref|email|ftpsite|ftppath !entity % list list|enumlist|taglist !entity % inline (#pcdata|%emph|%xref|footnote)+ !entity % inpara ((%inline)|(%list)|example)+ !entity % paras (p+) !entity % sect heading,(%paras)? !element titlepag o o (title,author+,version?,abstract?,copyright?) !element title - o (%inline) !element author - o (name,email) !element name o o (%inline) -(email) !element email o o (#pcdata) !element version - o (#pcdata|date)+ !element date - o empty !element abstract - o (%inpara) !element copyright - o (copyrightsummary,p*) !element copyrightsummary o o (%inpara) !element toc - o empty !attlist toc detail (chapt|sect|sect1|sect2) sect !element heading o o (%inline) -(%xref) !element chapt - o ((%sect),sect*) !element sect - o ((%sect),sect1*) !element sect1 - o ((%sect),sect2*) !element sect2 - o ((%sect),sect3*) !element sect3 - o ((%sect),sect4*) !element sect4 - o (%sect) !attlist chapt id cdata #implied !attlist sect id cdata #implied !attlist sect1 id cdata #implied !attlist sect2 id cdata #implied !attlist sect3 id cdata #implied !attlist sect4 id cdata #implied !element footnote - - (%paras) !element p o o (%inpara) !element em - - (%inline) -- emphasis -- !element var - - (%inline)-- metasyntactic variable or text -- !element prgn - - (%inline) -- (short) name
dpkg 1.3.3: manuals included, source packaging improvements
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 10 Aug 1996 23:05:41 +0100 Source: dpkg Binary: dpkg Architecture: source i386 Version: 1.3.3 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: dpkg - Package maintenance system for Debian Linux Changes: dpkg (1.3.3) experimental; urgency=low . * Programmers' policy manuals in source tree; HTML in /usr/doc/dpkg. * Old guidelines.info and text files in /usr/doc/dpkg removed. . * dpkg-source sets permissions on extracted debianised source tree and does not copy ownerships out of archive even if running as root. . * Emacs mode `dpkg changelog' renamed to `Debian changelog'. * Default changelog format renamed from `dpkg' to `debian'. . * debian-changelog-mode sets fill-prefix correctly. * debian-changelog-mode urgencies except HIGH lowercase by default. * debian-changelog-mode displays keymap in doc string and so mode help. . * More maintainers' PGP keys. . * Remove built changelog parsers with `clean' target in source. Files: 739da72ea6c9199f705e38681c2a8d2e 526 base required dpkg_1.3.3.dsc d77c56df3b1a78d95b95034eda16ba19 441282 base required dpkg_1.3.3.tar.gz 12f7053498af791ec8aaa38dfbab698d 295492 base required dpkg_1.3.3_i386.deb e299f322b5565888f3292e762c67c896 290212 byhand - dpkg_1.3.3_i386.nondebbin.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg0JKsMWjroj9a3bAQGFkQP9ErA0HYqClGHX+Bk2MF+XX8FhTwh3c9uV 06LQbKtk7fOwR8oqhnOZm52gAEJucxWvX/n1bXyok27ClZCl4XkICHD8NXm9ePJG NIAeRogzOPBjfrBq0jIeGLxWOnxRzfrlmSG5dg5x3qNkfXOJCY7DAV26G0S7xkHM s2+FK+UWaug= =8Ezh -END PGP SIGNATURE-
dpkg 1.3.3: manuals included, source pkg improvements - really
Oops, the first time I forgot to remove the call to install-info for the guidelines from the postinst. This would be the one time I forget to do a test-install ... I've released a new 1.3.3 and replaced the old one in the upload queue. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 10 Aug 1996 23:35:51 +0100 Source: dpkg Binary: dpkg Architecture: source i386 Version: 1.3.3 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: dpkg - Package maintenance system for Debian Linux Changes: dpkg (1.3.3) experimental; urgency=low . * Programmers' policy manuals in source tree; HTML in /usr/doc/dpkg. * Old guidelines.info and text files in /usr/doc/dpkg removed. . * dpkg-source sets permissions on extracted debianised source tree and does not copy ownerships out of archive even if running as root. . * Emacs mode `dpkg changelog' renamed to `Debian changelog'. * Default changelog format renamed from `dpkg' to `debian'. . * debian-changelog-mode sets fill-prefix correctly. * debian-changelog-mode urgencies except HIGH lowercase by default. * debian-changelog-mode displays keymap in doc string and so mode help. . * More maintainers' PGP keys. . * Remove built changelog parsers with `clean' target in source. Files: a1322f6f9ed71221d5d9b029c0dfc6c4 526 base required dpkg_1.3.3.dsc 8c9b7c5e303eb7727034fac1f4547548 441045 base required dpkg_1.3.3.tar.gz d665903e45206c15f441a230a77b68ba 295462 base required dpkg_1.3.3_i386.deb 7677dacd8e69bde33b9ed85184670f49 290208 byhand - dpkg_1.3.3_i386.nondebbin.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg0QUcMWjroj9a3bAQFbEAP/YjjRR2vRhhTaRHk1sYLzFYnebkPjaYLq BktcBx1rzeegJY5eQ7iZDRhkLR31NsRGpTXB7fZVAHtdaZaqvum2oLu0x+P/c+HZ QguVGee+F8vtw9o11MFLh8Biw5ZXlq3yxh3lJFBy5wg+nWbwBvdthe0e1+2c+Rry JOQEsR3jGhY= =HML1 -END PGP SIGNATURE-
hello 1.3-9: extra comment in debian/rules
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 10 Aug 1996 22:23:39 +0100 Source: hello Binary: hello Architecture: source i386 Version: 1.3-9 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: hello - The classic greeting, and a good example Changes: hello (1.3-9) experimental; urgency=LOW . * changelog specifies `debian-changelog-mode', not `dpkg-...'. * Comment in debian/rules re missing (obsolete) `source', `diff' c. Files: 0d01a3c12d6e109ed075416fba55ef63 585 devel optional hello_1.3-9.dsc 032210c7db1f7aac12b337cdc3b0b37f 87701 devel optional hello_1.3.orig.tar.gz 425860fd00676ac1cc220af67a918d22 2939 devel optional hello_1.3-9.diff.gz 42d43f5b9143d7e16919872d50a3ba98 13718 devel optional hello_1.3-9_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg0GMcMWjroj9a3bAQG2CwQAwnpBIT5fjLjfpgje8pgAr+PZmd6b0azJ 2L1KALbcVmFLzMLc0XeU3omgygUTzZb1L73/nQbWNsMH0/0RSqVeyiel6OBCjbJb PBRD2MicDAZ4sjGaiZWHdENcl+sMDPEpkXt7e1HCHdM3ES9J5zZwAIxessE390VH 87Y12NkJdbo= =aion -END PGP SIGNATURE-
debiandoc-sgml 1.0.1: bugfix
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 11 Aug 1996 13:26:27 +0100 Source: debiandoc-sgml Binary: debiandoc-sgml Architecture: source all Version: 1.0.1 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: debiandoc-sgml - Documentation formatting for Debian manuals Changes: debiandoc-sgml (1.0.1) experimental; urgency=low . * Fixed misplaced bracket in Lout formatter. Files: 1192918b3363418ff3646102c110a9a3 555 text optional debiandoc-sgml_1.0.1.dsc 184eb717e77bab0659ea81973b214e66 23878 text optional debiandoc-sgml_1.0.1.tar.gz 77ab6859e94749f39e2cdb39b0a829c4 12834 text optional debiandoc-sgml_1.0.1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg3S+cMWjroj9a3bAQFEdQP6A31CIC6DOM0mg3wc17cdwEfCOOQv7WFX bFRKeyAfzdYDKoCsZxZr6A3Q/aYzy/vokIbhj+pV/gZbgum+3x8q8TCvI9TPYxeB z3uJBXFyxlZrgUuYR0D3wvtrVSUTBzrVq3G63NqMCt43fbemPKU8Q0eB/URo/MKn epE6QUlC8Pg= =dcrp -END PGP SIGNATURE-
