EurOpen.SE meeting
We (EurOpen.SE) would like to have some one from the Debian project to present the project and OS at our meeting in Oct 24-25. I've tried to reach some of you via [EMAIL PROTECTED], but without any luck. Please let me know who I should contact. Håkan [EMAIL PROTECTED] (@ work) [EMAIL PROTECTED] (@ home) [EMAIL PROTECTED] (EurOpen.SE staff)
Bug#4472: apache out of date
I know. My 1.1.1 package is ready and I will upload it this week, I think. Yves. -- Yves Arrouye Email: [EMAIL PROTECTED] 7, avenue Leon BolleeWeb: http://www.fdn.fr/~yarrouye/ 75013 Paris Work: +33 45 95 64 59 France Home: +33 53 61 09 55
Re: dpkg and dependencies - manual update
Thanks, Guy, for clarifying that issue. I've added the following to the programmers' manual: When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency. Some packages are composed of components of varying degrees of importance. Such a package should list using tt/Depends/ the package(s) which are required by the more important components. The other components' requirements may be mentioned as Suggestions or Recommendations, as appropriate to the components' relative importance. Ian.
Use of dpkg-divert - new policy
Prompted by the recent problem with ADA and /usr/bin/gcc, I've added the new rule below to the policy manual in dpkg 1.4.0. Ian. sectUse of prgn/dpkg-divert/ and prgn/update-alternatives/ p Do not use prgn/dpkg-divert/ on a file belonging to another package without consulting the maintainer of that package first. p In order for prgn/update-alternatives/ to work correctly all the packages which supply an instance of the `shared' command name (or, in general, filename) must use it. You can use tt/Conflicts/ to force the deinstallation of other packages supplying it which do not (yet) use prgn/update-alternatives/. It may in this case be appropriate to specify a conflict on earlier versions on something - this is an exception to the usual rule that this is not allowed.
diff_2.7-11 uploaded to master
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Tue, 10 Sep 1996 23:33:40 -0400 Source: diff Binary: diff Architecture: source i386 Version: 2.7-11 Distribution: unstable Urgency: low Maintainer: Dale Scheetz [EMAIL PROTECTED] Description: diff - File comparison utilities Changes: diff (2.7-11) unstable; urgency=low . * Updated package to Standards-Version 2.1.0.0. Files: 353e33462b896607ae23960c3087fbea 542 base required diff_2.7-11.dsc f4a16d4aa1107536b13ad1bc2a19b1c8 310758 base required diff_2.7.orig.tar.gz 919b19f3abe89f1584c49f796912e484 14887 base required diff_2.7-11.diff.gz 0aaa3002636bfa3526abdce175e852f5 185458 base required diff_2.7-11_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQB1AwUBMjY0JJEoh1qC3Q5lAQFuwQL9E2UxopSpBbXGzpeY2sOIhMIsgP6hUgDw hCTit050wjmkiqp0DzKorEQgtPBo9wLAtffv48Yf2lsFIjPsyO12Y82JLj6T90Ji M7a8XreC16Qfw3Zu06zs0yBEbjDo9z1e =zR+z -END PGP SIGNATURE- Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: Bug#4475: Pine dies unexpectedly
On Wed, 11 Sep 1996, Nikhil Nair wrote: Package: pine Version: 3.94-2 Pine, ever since I upgraded to this version, has crashed on me frequently. It seems to happen if I fail to hit a key for a while, as if it's some sort of timeout, but that's not the only time it does it. No coredump, and no message saying Pine terminating or anything like that. I've been running pine with the `open' command to put it in a fresh VC; I Is there some compelling reason for doing it this way? Do you use any options with the open command? Do you use the open command on any other programs? Do they work properly? haven't observed this behaviour when running it from an ordinary shell, so maybe it doesn't like being a session leader. Also, I tried running it under strace, but it wouldn't crash! - that seems to confirm this conclusion. This is *very* annoying ... Well, like the doctor said: If it hurts when you do that, just don't do that. ;-) Seriously, I'll see what I can figure out. Luck, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4476: Remove error-message activism :-)
Package: xpdf Version: 0.5-0 More of a misfeature than a bug. There is an error message that pops up when xpdf tries to open an encrypted PDF file. It complains that Adobe has not released decryption specs to developers, and implores the user to e-mail Adobe to complain. The latest information at the xpdf home page states that Adobe has finally released the decryption specs. It also says that a new version of xpdf is in the works, but its release is uncertain. It might be wise to change the error message until a new version of xpdf is released by the author. Just a polite gesture more than anything else. :-) This is the error message in question: Error (0): PDF file is encrypted and cannot be displayed Error (0): * Please send email to [EMAIL PROTECTED] and ask Error (0): * them to prove that PDF is truly an open standard by Error (0): * releasing the decryption specs to developers. Also, Error (0): * please send email to the person responsible for this Error (0): * file ([EMAIL PROTECTED] might be a good place) and ask Error (0): * them to stop using encrypted PDF files. -- Larry Gilbert, technical support (Bess Rainier.Net) [EMAIL PROTECTED]
Bug#4477: Emacs doesn't use /etc/mailname
Package: emacs Version: 19.31-2 -chiark:~ grep mailname /var/lib/dpkg/info/emacs.* -chiark:~ cat /etc/mailname chiark.greenend.org.uk -chiark:~ hostname -f chiark.chu.cam.ac.uk -chiark:~ But, after C-h C-v mail-host-address RET: -Emacs: *scratch* 12:40am 0.34 Mail (Lisp Interaction)--L1--All mail-host-address's value is nil Documentation: *Name of this machine, for purposes of naming users. -Emacs: *Help* 12:40am 0.34 Mail (Help View)--L1--All--- Ian.
Ian Jackson's availability over the next weeks/months
It's coming up to my thesis deadline (well, my funding is starting to look thin), so I'll be spending somewhat less time on Debian over the next few weeks/months. I'm about to release dpkg 1.4.0, which will probably be the last one for several weeks. I'm going to be away for a week or so soon, and very busy househunting, jobhunting and writing up the rest of the time. Expect replies to your email to take a long time. I really appreciate it when people answer each other's questions on debian-devel about dpkg c., even if some of them are wrong. I can always post saying `Joe Smith is right' :-). If there is a grievous bug in dpkg (or my other packages) then someone else may have to fix it. If you wish to do this please (a) be sure you understand the code, (b) make the minimal fix (obviously) until I can get round to it, (c) mail the patch and rationale to [EMAIL PROTECTED] or [EMAIL PROTECTED], (d) use version numbers like 1.4.0.1 (ie, add a new component) and (e) correspond on debian-devel to avoid simultaneous releases. Please don't make releases with any major changes. If the policy or programmers' manuals need updating then Guy or Bruce or someone ought to approve the change. I will still be reading debian-devel and my email, and if something really needs my input I'll pop up and pontificate. Things that I'm really sorry I haven't got round to in dpkg are: * Configuration files (rc files) for dpkg/dselect, and associated extra configurability. I want this done the way I have in mind, so I'd like it left to me. * New user interface for dselect. This is potentially something someone else could write. It only has to replace the `select' part of dselect, and integration can be done some other time. While testing it could even be a separate program. * System administrators' manual, and complementarily the manpage dpkg(8). If someone else wants to write this, fine, but you have to be _very_ familiar with the way dpkg works. I don't have the time to spend editing and correcting something in detail, so if you get it wrong you'll just get a message back from me saying `sorry, it's techically inaccurate, I'm not shipping it.' * See the WISHLIST (TODO in the source package). There are many things there that individually wouldn't take up so much time ... I expect to be in a new job and house by the end of November, and a month or two after that I expect to be with you again in full. Ian. PS: I feel really uncomfortable putting my name in the Subject line like that :-).
debian-manuals 2.1.1.0: minor changes
This is the version in dpkg 1.4.0 (in dpkg-dev). debian-manuals (2.1.1.0) unstable; * Hard links are forbidden in source packages (they didn't work anyway, and can't easily be made to work reliably). * Do not use dpkg-divert or update-alternatives without consultation. * Do not need to declare dependencies on Essential packages. * Restrictions on Pre-Depends stated in policy manual. * debian/substvars file is now almost always auto-generated. * Shared libraries must be installed stripped. * Essential and Pre-Depends put together in policy manual. * Explained component-wise (file-wise) vs. package-wise dependencies. -- Ian Jackson [EMAIL PROTECTED] Thu, 12 Sep 1996 01:00:41 +0100
Re: Bug#4475: Pine dies unexpectedly
On Wed, 11 Sep 1996, Dale Scheetz wrote: On Wed, 11 Sep 1996, Nikhil Nair wrote: [...] I've been running pine with the `open' command to put it in a fresh VC; I Is there some compelling reason for doing it this way? Do you use any options with the open command? Do you use the open command on any other programs? Do they work properly? I use open together with dynamic-vc to implement a sort of terminal-based full-screen windowing system (as I can't use X). I do something like $ open -s -- command args (shortened by a shell script :-) ). In this case it's pine with no arguments. I've been using this for over a year, and run almost everything I use in this fashion. For all of that time, I've been using a previous version of pine (I think it was 3.91 or something ...) with no problem. Nikhil. -- Nikhil Nair Trinity College, Cambridge, England Tel.: +44 1223 368353 Email: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Shared libraries and version handling
On Wed, 11 Sep 1996, Dale Scheetz wrote: Is there a method of picking up this information [package version] from a central source in the package? You can just do what dpkg does - parse the changelog: /usr/lib/dpkg/parsechangelog/debian debian/changelog | \ sed -n '/Version: /s///p' If you use a different changelog format, you'll have to call your parser instead. If you want just the major number for an soname, use '/Version: \(.*\)\..*/s//\1/p' as the sed command. Guy
Who is doing the libc6 package?
Who is doing the libc6 package? It would be interesting to see how much of our stuff builds and runs off of this, and how much trouble it has with shadow password, etc. It also changes the format of some configuration files, I fear. I noticed a different format for the resolver configuration file. We should figure out what we are doing about that. Thanks Bruce From: Ulrich Drepper [EMAIL PROTECTED] Hi, I'm pleased to announce the next test release of the GNU C library. Again my errors are fixed and many enchancements were implemented. The complete sources are available at ftp://alpha.gnu.ai.mit.edu/gnu The bad news is that this release does not work for Hurd yet. We hope that future versions will not have this problem anymore but in the moment there are a few problems. The main changes: - the building process should now run faster when a separate building directory is used. Andreas Schwab changed the Makefiles so that they create subdirs according to the structure of the sources. This avoids the huge directory which was used before. - the add-on mechanism should now work correctly. Using this technique one can add additional code which is compiled as part of glibc. This can also be used to overwrite code from the original glibc sources. Currently two add-ons are available: * crypt, Michael Glad UFC package * LinuxThreads by Xavier Leroy Both packages are available together with the sources. Simply unpack the sources in the glibc toplevel dir and run configure with the --enable-add-ons option. IMPORTANT!!! Do *not* download the crypt package from the FSF server when you are outside the US or Canada. I have made all files (the libc and the add-ons) also available on ftp://i44ftp.info.uni-karlsruhe.de/pub/linux/libc/glibc-pre2 - enchanced thread support for Linux. In fact I expect that we are close to a thread safe libc. The hooks for glibc are available when the LinuxThreads add-on is available. Some tests already run but the stdio implementation still has a few problem (partly caused by the not yet finished thread library). - more and better message translations available For more details please look through the changes. The situation for ports other than to Hurd or Linux didn't changed. There is still nobody interested in seeing glibc-2.0 on other platforms. As alawys, send comments or bug reports to [EMAIL PROTECTED] Please always include the output of a run of the libc.so object in the mail (yes, executing the libc shared library itself produces some output). Thanks, -- Uli --. [EMAIL PROTECTED] ,-. Rubensstrasse 5 Ulrich Drepper \,' \ 76149 Karlsruhe/Germany Cygnus Support `--' [EMAIL PROTECTED] `
Re: Shared libraries and version handling
: I've been working on converting the gmp package to the new source format
: and adding shared libraries to the package at the same time. Since version
: tagging no longer takes place in debian/rules I have had to hard code the
: so version numbers into both the rules and the Makefile. I have looked
: through the new docs with no success (my index karma again probably). Is
: there a method of picking up this information from a central source in the
: package?
I think about doing somethink like an imaginary dpkg-substvars. It
should
* obtain the variables values from central cource
(debian/substvars) or from within the dpkg-* library
routines (see docs for available vars (e.g. ${Source-Version}))
and
* output the contents of a specified variable
to be uses like:
dpkg-substvars --print Source-Version
and/or
* filter (a la sed) and substitute varibles
to be used like:
dpkg-substvars debian/shlibs debian/tmp/DEBIAN/shlibs
What do you think about?
(Or have I missed such nice tool? (Having dpkg-1.3.14).
Heiko
--
email : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
pgp : A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92
finger: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: automated uploading to chiark.
Heiko Schlittermann writes: for you in Europe, using chiark as relay to master.debian.org ... since the procedure of uploading to Incoming and moving to ../queue is somewhat error prone, I've written a little perl script (using ftp.pl and lchat.pl from the mirror package) to do this for me. If somebody is interested in, please mail me. Yes! Yes! Yes! :-) Features: * using *.changes file to determine the files to be uploaded * checking the md5 sums before starting further processing * logging of uploads (preventing duplicated uploads) * moving around on the ftp server, if necessary * sending mail to debian-changes after debian-changes? Shouldn't this be debian-devel? completed upload of every package Where can I get ifrom? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Bug#4465: security hole in netdiag package
Peter Tobias writes: Package: netdiag Version: 0.2-3 The postinst script copies the tcpdump binary from the tcpdump package and the traceroute binary from the netstd package to /usr/bin and makes them setuid root.adm. This allows all users in the existing adm group to use tcpdump to get the unencrypted passwords that are transmitted over the network. This is a real problem. But you probably cannot really fix it since you stil have that possibily via another machine. My collegue tried this in recent weeks and wondered why it didn't work until I told him about ssh. :-) IMHO the netdiag package shouldn't use tcpdump/traceroute (neither as binaries nor as links). Copying/linking binaries from other packages just to have them in /usr/bin is a bad idea. Maybe something like this should be added to the guidelines. Totally agreed. Just for curiosity, why were they moved anyway? Most users who know these tools will figure out how to start them from /usr/sbin anyway. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian GNU/Linux!| //_/ /_/ //\___/_/ //
Re: dpkg and dependencies - manual update
On Wed, 11 Sep 1996, Ian Jackson wrote: Thanks, Guy, for clarifying that issue. I've added the following to the programmers' manual: When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency. Some packages are composed of components of varying degrees of importance. Such a package should list using tt/Depends/ the package(s) which are required by the more important components. The other components' requirements may be mentioned as Suggestions or Recommendations, as appropriate to the components' relative importance. For me, this is still inadequate. Subjective phrases like components of varying degrees of importance and required by the more important components do not lead all readers to the same conclusions. This importance of the components depends on the goals of the user. Thus, I find dpkg-buildpackage to be as important to me as dpkg and don't find dselect to be very important at all. (I realize that this is my personal point of view, and not shared by all others) It has been my understanding that the dependency feature of the package installation software is intended to provide the user with an installation where all functionality provided by a package will work when the package has been properly installed (with it's dependency requirements met first). The relative importance of the various functional components is irrelevant to this issue, since this is purely subjective. If some functionality is provided by a package, some indication of the other packages that are necessary for it's proper operation is absolutely necessary. If a bit of functionality is so unimportant as to not require reporting of it's dependencies then why was it included in the package in the first place? I have been thinking about a possible dependency problem with Pine. Pine uses ispell to do it's spell checking. If ispell is not properly installed, Pine complains, but does so in a way that provides no information to the user about what the problem is. (The error messages are pushed off the screen so fast as to be unreadable. The last message that appears is Spell checking complete) For me (heavily spelling impaired) the spell checker is an absolute necessity. For others it may be totaly unnecessary. How do I determin which level of depends to use (if any)? Help me decide which is correct by sending your suggestion via private e-mail. I will summarize the vote back to the list so we can see just how much consensus can be had on this kind of issue. Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Uploaded dupload_1.2_i386 to chiark
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Thu, 12 Sep 1996 17:44:04 +0200 Source: dupload Binary: dupload Architecture: source all Version: 1.2 Distribution: experimental Urgency: medium Maintainer: Heiko Schlittermann [EMAIL PROTECTED] Description: dupload- Utility to upload debian packages. Changes: dupload (1.2) experimental; urgency=medium . * silly bug prevented it from sending the announcement Files: a5aeee5519fec163fbde80e95cea4feb 536 misc extra dupload_1.2.dsc ec2bb774366903e8554b7314add0ec62 24579 misc extra dupload_1.2.tar.gz 18c859a111cc03c2cac44359f5511ef0 28594 misc extra dupload_1.2_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMjgv9dBsuuHx3GhhAQGonwQAsIQO4cUBAjxlcy6Pix35OV4LPz5QPDU1 pGnZFw5PdFsBvMHCQQcg8eTHo7aTQf8CYgNC3xranZdyS4m6RckGQAFgR76lCBhF 7Ek+xSwDjA0xto7T9Rj3gdgYOWpbt3nEZ9T0Cwjcfg9y/6zuQRY5Lkx1p7tMYdfA zbB5/XgnKwI= =vBKq -END PGP SIGNATURE-
Bug#4479: pine tries to use /bin/passwd
Package: pine Version: 3.94-3 When trying to do a (S)etup (N)ewpassword from the main menu of pine I get a message that /bin/passwd cannot be found. Debians passwd is in /usr/bin and not in /bin.
Changelog Format
Could somebody please point me to the changelog file format? I'm trying to build the new 'dftp' package but it keeps dieing on the changelog file. Please respond by email since I _still_ have not been able to subscribe to this list. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4480: Upgrading dpkg-ftp is a little broken
Package: dpkg-ftp Version: 1.4.3 After upgrading from 1.4.2, it wouldn't work without the user doing a setup again: -- Forwarded message -- Date: Thu, 12 Sep 1996 11:32:34 -0500 (CDT) From: Guy Maor [EMAIL PROTECTED] To: Debian User List debian-user@lists.debian.org Subject: Re: dpkg-ftp 1.4.3 On Thu, 12 Sep 1996, Alex Romosan wrote: i hate to answer my own questions, but after comparing the files in 1.4.2 to 1.4.3 i've discovered that 1.4.3 will let you set the download directory as opposed to 1.4.2 when it was hardcoded. so one needs to setup the access mode again and after that everything will work just fine. shouldn't this be done automatically when installing the package? i think it should. maybe we should consider this a bug. Yes, I think it's a bug. 1.4.3 could just wipe out the recorded data in its postinst, forcing you to resetup, or it could come with 1.4.2's hardcoded location as the default. I'll file a report. Guy
Bug#4454: Distribution: unstable' but it goes into project/experimental
Guy Maor writes (Re: Bug#4454: `Distribution: unstable' but it goes into project/experimental): ... The override files instructed dinstall to put debiandoc-sgml into experimental, overriding what was in the .changes file. Ergh. This problem will recur whenever a package moves from one section or distribution to another. dinstall cannot handle this case because it doesn't know where to look for the older version to unlink it. Couldn't it look in the override file ? Instead it assumes that the .changes file listed incorrect sections and distributions (a fairly frequent occurrence actually), and installs the package into the old location. Since package movements are much more rare than .changes files with incorrect locations, dinstall's assumption is the right one. I think that we should try to make .changes files right. I think the new source format will help here. (dchanges made it very easy to say `Distribution: unstable' without thinking.) dinstall could, alternatively, require human intervention in this case. But it was written to run as automatically as possible. It will make a recoverable error, which is usually the right thing to do, rather than do nothing at all. Thanks. A third alternative is to turn the `Override file lists section as ... overriding your choice of ...' message into an error, so the package would get rejected. But this is illogical as it would require MORE intervention: maintainers would be forced to reupload new .changes files and the distribution maintainer would still have to edit the override file. So I would like to close this bug, as it's not a bug. Of couse, you may be able to suggest a fourth alternative which is better. Could you report the bad Distribution as a bug, if it turns out to be true ? Ian.
Bug#4481: Kernel-related dd bug
Package: fileutils Version: 3.12-4 Under a recent kernel, dd seems to produce spurious extra output *only* if stdout isn't redirected ... $ echo 'This is a test.' | dd of=/tmp/testing bs=10k conv=sync 0+1 records in 1+0 records out $ wc /tmp/testing 1 5 10240 /tmp/testing $ dd if=/tmp/testing bs=10k count=1 This is a test. This is a test. 1+0 records in 1+0 records out $ dd if=/tmp/testing bs=10k count=1 | cat This is a test. 1+0 records in 1+0 records out $ uname -a Linux amasis 2.0.17 #2 Thu Sep 5 00:58:46 BST 1996 i586 $ On an older kernel (everything else the same): $ echo 'This is a test.' | dd of=/tmp/testing bs=10k conv=sync 0+1 records in 1+0 records out $ wc /tmp/testing 1 5 10240 /tmp/testing $ dd if=/tmp/testing bs=10k count=1 This is a test. 1+0 records in 1+0 records out $ dd if=/tmp/testing bs=10k count=1 | cat This is a test. 1+0 records in 1+0 records out $ uname -a Linux amasis 1.3.21 #4 Thu Jan 4 21:02:19 GMT 1996 i586 $ Very odd ... Nikhil. -- Nikhil Nair Trinity College, Cambridge, England Tel.: +44 1223 368353 Email: [EMAIL PROTECTED] [EMAIL PROTECTED]
Bug#4482: dpkg-genchanges `-u' option not implemented
Package: dpkg-dev Version: 1.4.0 The `-u' option in the dpkg-genchanges script has not yet been implemented. From the man page: -uuploadfilesdir Look for the files to be uploaded in uploadfilesdir rather than .. (dpkg-genchanges needs to find these files so that it can include their sizes and checksums in the .changes file). From `dpkg-genchanges -h': Usage: dpkg-genchanges [options ...] Options: ... -uuploadfilesdir directory with files (default is `..')
Bug#4454: Distribution: unstable' but it goes into project/experimental
On Thu, 12 Sep 1996, Ian Jackson wrote: Guy Maor writes (Re: Bug#4454: `Distribution: unstable' but it goes into project/experimental): This problem will recur whenever a package moves from one section or distribution to another. dinstall cannot handle this case because it doesn't know where to look for the older version to unlink it. Couldn't it look in the override file ? How would it know that if the discrepency was a mistake in the .changes file or a moving package? I should have said that dinstall can't handle this case because it can't differentiate it from an incorrect .changes file. Instead it assumes that the .changes file listed incorrect sections and distributions (a fairly frequent occurrence actually), and installs the package into the old location. Since package movements are much more rare than .changes files with incorrect locations, dinstall's assumption is the right one. I think that we should try to make .changes files right. I think the new source format will help here. (dchanges made it very easy to say `Distribution: unstable' without thinking.) Yes, that caused problems for me because I had to make certain sections special, mapping to distributions with the same name. unstable/contrib, for instance, maps to contrib/contrib. The new source format certainly helps, but it doesn't guarantee that this won't happen. That reminds me to obsolete dchanges. Plenty of people are using the old format, but I'd like to discourage it. Could you report the bad Distribution as a bug, if it turns out to be true ? I will make dinstall warn if there was a mistake in the .changes's Distribution field. Guy
Re: automated uploading to chiark.
On Wed, 11 Sep 1996, Michael Meskes wrote: Heiko Schlittermann writes: Features: * sending mail to debian-changes after debian-changes? Shouldn't this be debian-devel? No, see policy manual 6.4. Guy
