Re: debian lists sent to anon.petet.fi ??
Miquel van Smoorenburg [EMAIL PROTECTED] said: And I got this back from the anon.petet.fi gateway. The interesting thing is that my collegue got *exactly* the same mail from the anon.petet.fi gateway and he sent a bug report to [EMAIL PROTECTED] only, no Cc:'s. Ditto with a bug report I sent yesterday to [EMAIL PROTECTED], with no Ccs. + From [EMAIL PROTECTED] Sun Jun 30 08:24:52 1996 + Date: Sat, 29 Jun 96 23:01:51 +0300 + From: [EMAIL PROTECTED] + To: [EMAIL PROTECTED] + Subject: Anonymous service rejected your mail. + + You, [EMAIL PROTECTED], have requested anonymous mail forwarding to + dade. This was rejected, as the user is unknown. + + Contents of message follows: + + From: [EMAIL PROTECTED] + X-Anonymously-To: dade + Organization: Anonymous forwarding service + Reply-To: [EMAIL PROTECTED] + Date: Sat, 29 Jun 1996 20:01:50 UTC + Subject: Bug#3443: mechanism for dealing with orphan packages + [...snipped...] Pine saved the following header from the outgoing message: From [EMAIL PROTECTED] Sat Jun 29 06:45:30 1996 Status: O X-Status: Date: Sat, 29 Jun 1996 06:45:29 -0700 (PDT) From: Bill Mitchell [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mechanism for dealing with orphan packages In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII
Departure -- hopefully temporary
I'm afraid that I must drop off the debian project for now. I'm still on track to drop off the net around mid July, due to relocation to the Philippines, and I need to spend a larger portion of my time getting ready for the move. I'm not sure where in the Philippines I'll end up, or whether a net connection will be workable from wherever that may be. Hopefully, I'll be rejoining the project in a couple of months. I'm unsubscribing from the lists as of today, but I'll still be reachable by email for the next couple of weeks. I've been involved in the debian project since day one, and it's been a good experience. We've produced a top-notch distribution, but it's still got some rough edges. I think some of those rough edges would have been smoother if we'd made a few design decisions differently. In those areas where the rough edges really matter, the design decisions which they grow out of will get re-thought to smooth out the roughness. That's already happened in a couple of areas. Most of my packages have found homes. I have three packages left, one of which is an important one. I'm afraid that they're now orphans. The following is disposition information on my former packages: bc-1.03 gone to Austin Donnelly [EMAIL PROTECTED] cvs-1.8.1 gone to [EMAIL PROTECTED] diff-2.7gone to Dale Scheetz [EMAIL PROTECTED] ed-0.2 gone to Austin Donnelly [EMAIL PROTECTED] file-3.19 gone to Darren/Torin/Who Ever... [EMAIL PROTECTED] indent-1.9.1gone to Steve Greenland [EMAIL PROTECTED] jgraph-83 ORPHAN patch-2.1 gone to Darren/Torin/Who Ever... [EMAIL PROTECTED] sharutils-4.2 gone to [EMAIL PROTECTED] symlinks-1.0gone to [EMAIL PROTECTED] # need ncurses for these ae-962 ORPHAN (important) beav-140ORPHAN less-290gone to Darren/Torin/Who Ever... [EMAIL PROTECTED] git-4.3.9 gone to Klee Dienes [EMAIL PROTECTED] ee-126.1.89 gone to Steve Greenland [EMAIL PROTECTED] elvis-2.0 gone to Susan G. Kleinmann [EMAIL PROTECTED] # need elf X11 xasteroids-5.0 gone to Klee Dienes [EMAIL PROTECTED] # not elf-ized yet kermit-190 gone to Susan G. Kleinmann [EMAIL PROTECTED] [EMAIL PROTECTED] (Bill Mitchell)
Unarj 2.41a-4 uploaded
Date: 30 Jun 96 15:46 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Karl Ferguson [EMAIL PROTECTED] Source: unarj Version: 2.41a-4 Binary: unarj Architecture: i386 source Description: unarj: Unarj unarchive utility. Changes: unarj: Fixed indented long description bug. Files: f87d8c3a98d532960a5c7e44a8994526 59624 misc - unarj-2.41a-4.tar.gz 7e7726d29439c567813dd26e49522e3c 3170 misc - unarj-2.41a-4.diff.gz c5cb4b7d811f3fb636aa1d2420108ca9 15424 misc optional unarj-2.41a-4.i386.deb ...Karl -- Karl Ferguson, Tower Networking Pty Ltd (ACN: 072 322 760) [EMAIL PROTECTED] t/a STAR Online Services [EMAIL PROTECTED] Tel: +61-9-455-3446 Fax: +61-9-455-2776
Re: Departure -- hopefully temporary
If no one else wants it, I think I have room on my plate for ae. Is the bug still outstanding? On Sun, 30 Jun 1996, Bill Mitchell wrote: I'm afraid that I must drop off the debian project for now. I'm still on track to drop off the net around mid July, due to relocation to the Philippines, and I need to spend a larger portion of my time getting ready for the move. I'm not sure where in the Philippines I'll end up, or whether a net connection will be workable from wherever that may be. Hopefully, I'll be rejoining the project in a couple of months. I'm unsubscribing from the lists as of today, but I'll still be reachable by email for the next couple of weeks. I've been involved in the debian project since day one, and it's been a good experience. We've produced a top-notch distribution, but it's still got some rough edges. I think some of those rough edges would have been smoother if we'd made a few design decisions differently. In those areas where the rough edges really matter, the design decisions which they grow out of will get re-thought to smooth out the roughness. That's already happened in a couple of areas. Most of my packages have found homes. I have three packages left, one of which is an important one. I'm afraid that they're now orphans. The following is disposition information on my former packages: bc-1.03 gone to Austin Donnelly [EMAIL PROTECTED] cvs-1.8.1 gone to [EMAIL PROTECTED] diff-2.7gone to Dale Scheetz [EMAIL PROTECTED] ed-0.2 gone to Austin Donnelly [EMAIL PROTECTED] file-3.19 gone to Darren/Torin/Who Ever... [EMAIL PROTECTED] indent-1.9.1gone to Steve Greenland [EMAIL PROTECTED] jgraph-83 ORPHAN patch-2.1 gone to Darren/Torin/Who Ever... [EMAIL PROTECTED] sharutils-4.2 gone to [EMAIL PROTECTED] symlinks-1.0gone to [EMAIL PROTECTED] # need ncurses for these ae-962 ORPHAN (important) beav-140ORPHAN less-290gone to Darren/Torin/Who Ever... [EMAIL PROTECTED] git-4.3.9 gone to Klee Dienes [EMAIL PROTECTED] ee-126.1.89 gone to Steve Greenland [EMAIL PROTECTED] elvis-2.0 gone to Susan G. Kleinmann [EMAIL PROTECTED] # need elf X11 xasteroids-5.0 gone to Klee Dienes [EMAIL PROTECTED] # not elf-ized yet kermit-190 gone to Susan G. Kleinmann [EMAIL PROTECTED] [EMAIL PROTECTED] (Bill Mitchell) 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: Departure -- hopefully temporary
Bill Mitchell [EMAIL PROTECTED] writes: OK, I'll take this one. jgraph-83 ORPHAN Good luck Bill. Hope your move goes well. -- Rob
Re: Departure -- hopefully temporary
On Sun, 30 Jun 1996, Dale Scheetz wrote: If no one else wants it, I think I have room on my plate for ae. Is the bug still outstanding? You're the first one to speak up, so I guess it's yours. I've cleared the multi-arch compatability bug in ae, and made similar changes to clear the same problem in my other two orphaned packages, beav and jgraph. On ae -- I'm out of touch with the upstream author. He was formerly reachable as Anthony Howe [EMAIL PROTECTED], but he dropped off the net back in February due to relocation to France. He was expecting to be back in touch in May, but I haven't heard from him. The ae upstream sources are a private set of sources which grew out of Anthony's bugfix work on things which turned up as ae was shaken down in Debian. He hadn't made a public release with that source set before he dropped out of touch.
Re: unsubscribe mitchell@mdd.comm.mot.com
Agh!! Sorry.
my last three packages
I've unsubscribed, so this may not get through. If it does make it, it'll let the group know that my remaining three packages have been picked up by: jgraph-83 gone to Rob Browning [EMAIL PROTECTED] ae-962 gone to Dale Scheetz [EMAIL PROTECTED] beav-140gone to Klee Dienes [EMAIL PROTECTED] [EMAIL PROTECTED] (Bill Mitchell)
unsubscribe
unsubscrip [EMAIL PROTECTED] thanks
zircon-1.17p1-1
-BEGIN PGP SIGNED MESSAGE- Date: 30 Jun 96 17:56 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson [EMAIL PROTECTED] Source: zircon Version: 1.17p1-1 Binary: zircon Architecture: i386 source Description: zircon: An X11 interface to Internet Relay Chat. Changes: Upgraded to new version. Files: 4bdcd14f3a149a34986704b1ee1c31a4 199713 net - zircon-1.17p1-1.tar.gz 402bf20fe9f89c7b9835ea9996e43238 10226 net - zircon-1.17p1-1.diff.gz b9c30885fb5a62a2cfc87dfa04543d9e 198632 net extra zircon-1.17p1-1.i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMdbADiu/XyBsR8PBAQG6NgQAjkz8oI+xFsTMeaTZsei9KkL4DTRoh3hL 3DD7a57heDAxDQVQwhXQEiVb4QLb0RaZKAKwY2pHgx/Nubm5BVEx4Wl9YqffmBxS YWuR2g175CHmL5nWy2Azu/htOU8lkrWPZtKfXPiIcR87nlbjlF2Z2HjLdiCXPnl0 FuEB/CFTfuE= =yAz9 -END PGP SIGNATURE-
auctex-9.3c-3
-BEGIN PGP SIGNED MESSAGE- Date: 23 Jun 96 22:50 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson [EMAIL PROTECTED] Source: auctex Version: 9.3c-3 Binary: auctex Architecture: i386 source Description: auctex: An integrated environment for writing TeX/LaTeX documents. Changes: Removed absolute paths from calls to install-info in scripts. Files: d14abbe8bc8ccb755d9aa326685ab49d 268996 tex - auctex-9.3c-3.tar.gz b4f9a8b20390beca4e14e73f8f92790c 270675 tex - auctex-9.3c-3.diff.gz 27d758771342c5d36f9ea4e2916881f6 324310 tex extra auctex-9.3c-3.i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMc3KbCu/XyBsR8PBAQEYrQP9HXa6pwC02y5zxMNl82dQvDLxwcDWZDpG 2Gztn6rAKMIRVz9K0KY/9N6KVfyegBqWg1iHBKzLOQdyD5Kbx7R7nxUNMcXtdYSC NNiWCK7bx6N3/EQGfYpvRBR4QhJ1tFfF7ArSHl3bT/TyYD51eStWW9mULksgqSye Xd7sbn5h8Ok= =iH8K -END PGP SIGNATURE-
Re: Bug#3368: cron's checksecurity still scans NFS servers
Austin Donnelly wrote: Package: cron Version: 3.0pl1-32 Recently, the checksecurity script bundled with cron was changed to not scan NFS servers. However, the regexp used to parse the output of mount is not quite right, and still fails to exculde the NFS servers. [correction snipped] Could the maintainer of the package (now Steve Greenland?) please make this change. Sorry about that. Thanks for the correction, I'll upload it this afternoon (6/30). Steve Greenland -- The Mole - I think, therefore I scream Max, did you order a talking monkey for this set? No, that's just a friend of the family. [Alternate Earth videos, from ZOT!]
Re: Bug#3368: cron's checksecurity still scans NFS servers
Dominik Kubla wrote: [checksecurity still descends down NFS links] And while we are at it: The same goes for AFS, ALEX and AMD filesystems, so please make the script ignore the AFS filetype and the following directories: /a /afs /alex /amd /n /net These directories have a special meaning to the named software products. They're also perfectly legitimate directory names having nothing to do with the named software products. I'll try to trap the afs type (not having access to that, will the nfs filter work by replacing 'nfs' with 'afs'?). However, it is my opinion that filtering by name is something best left to the individual administrator. Maybe some sort of config file is needed here? '/etc/checksecurity.conf'? Any objections? I'm thinking that checksecurity could source checksecurity.conf, which at present would define the single envirnoment variable FILTER, which would in turn be the argument to 'grep -vE'. If later additions were needed, it would be pretty straight forward. In fact, I should probably build FILTER up out of FILTER_TYPES, FILTER_OPTIONS, and FILTER_DIRS. Other ideas? SteveG -- The Mole - I think, therefore I scream MR. DeGUZMAN, YOUR DAYS ARE NUMBERED! That's Harris. DeGuzman is math. BAH! They're ALL scoundrels... [Zack, looking desperately for evil, from ZOT!]
Re: Bug#3370: httpdconfig installs Welcome.html even if index.html exists
Sven Rudolph wrote:
Package: cern-httpd
Version: 3.0-6
On upgrade httpdconfig is run. If there is no Welcome.html it creates
one.
However our legacy WWW data uses index.html as directory entry point.
CERN httpd first looks for Welcome.html, then for index.html, so our
WWW server provided the wrong page.
httpdconfig should only install Welcome.html when neither Welcome.html
nor index.html (and probably other files used in the same way by CERN
httpd or other httpd's) exists. When this isn't reliable enough, it
should at least ask whether it really shall install Welcome.html.
Ok, by default cern-httpd looks for Welcome.html, welcome.html, and
index.html, in that order. If any of those is installed, I'll not install
Welcome.html. If an admin has changed the default to something else, then
they can change the order as well, so I'm not going to worry about
that case, OK? (In other words, if you have the entry
Welcome {Welcome.html, hithere.html}
in your cern-http.conf file, you could just as easily reverse it.)
SteveG
--
The Mole - I think, therefore I scream
Why are many scientists using lawyers for medical
experiments instead of rats?
a) There are more lawyers than rats.
b) The scientist's don't become as
emotionally attached to them.
c) There are some things that even rats
won't do for money.
[Anonymous]
/etc/default? (was: Re: Bug#3368: cron's checksecurity still scans NFS servers)
[ NB: I read the list. Don't CC replies to me. I pay for my PPP. Thanks ] Steve Greenland: Maybe some sort of config file is needed here? '/etc/checksecurity.conf'? This might be an appropriate time to start thinking again about /etc/default (under whatever name). If I remember correctly, someone told us that one of the commercial vendors (or SVR4?) has a directory /etc/default, with shell scripts that set certain variables. This is used for configuration. When a program (script) needs the configuration, it sources the script. One of the benefits is that there's a lot of potential small configuration files like this, and it could be a bit neater to put them into the same directory. Examples: /etc/init.d/boot - is hardware clock GMT or local time? - should /etc/motd be updated automatically? httpd: what's the document directory? (if you don't want /home/httpd-data) /etc/init.d/console: name of font and keymap /etc/init.d/network: network configuration The point is that it is often easier to have the configuration and the script using it separate -- you can replace the script, but you don't have to make the user edit the new script to have the old configuration data. However, each script should have some sensible builtin defaults: if test -f /etc/default/checksecurity then . /etc/default/checksecurity else FS_DENY='nfs afs' DIR_DENY='' ... fi At least on my system, /etc/default already exists, and has the file /etc/default/console in it. pgpJxqAoEzh0o.pgp Description: PGP signature
Re: New source packaging format - requirements and proposal
Juergen Menden wrote: On Wed, 26 Jun 1996, Dale Scheetz wrote: The Debian Source Format could be composed of: 1. A control file. This would most likely be a diff file sufficient to reconstruct the Debianized source tree from the original pristine source tree. 2. A tar.gz file containing the original pristine source tree. bingo. thats it. the only point is, that these files should _not_ be included in a single source format! Let me weigh in with another vote for keeping two files: the original sources (not necessarily in their original form), and the 'debianize' file. The 'debianize' file could be a patch file along with a list of files that need their permissions changed and what those permissions would be. The dpkg suite would contain a tool to extract the patches (maybe just a callable gunzip/tar), apply the patches (probably just call patch, right?), and then apply those permissions.If you let the user choose whether to do the steps all at once or individually, then the user could look at the patches before they we're applied, and then look at the permissions file before _they_ we're applied. The only trust required would be in dpkg, and if you don't trust dpkg, then you can't use Debian anyway, right? My opinion is that anybody who wants to look at source is probably sufficiently competent to figure out how to get two files instead of one. Ian, I realize I'm creating extra work for youbut I think that (original source + debianize) does make more sense than (debian source + undebianize). SteveG -- The Mole - I think, therefore I scream Enough of this running shit. [Sean Connery on chase scenes, from THE UNTOUCHABLES]
Bug system enhancements
I think two additional functions to the bug handling system would be nice: send the outstanding bugs for a package send the outstanding bugs for a maintainer (If that functionality is already there, then it needs to be mentioned in the help response.) SteveG -- The Mole - I think, therefore I scream Riley, can you operate a road grader? Of COURSE! What kind of a question is that? [What kind of a question IS that? A normal BADGER question, of course...]
Unidentified subject!
Unsubscribe [EMAIL PROTECTED]
Bug#3437: fvwm should not recommend fvwm2
Christian Hudon wrote: Package: fvwm Version: 1.24r-24 Fvwm shouldn't recommend (nor even suggest, IMO) another version of itself (i.e. fvwm2). Hmm, I'm not so sure. In principle you are correct, but the fvwm2 package has all the pixmaps needed by fvwm-1.24 and fvwm won't run without them (at least not with my .fvwmrc). So unless the packages are reworked there may need to be a /dependency/ on fvwm2. -- Christopher J. Fearnley|Linux/Internet Consulting [EMAIL PROTECTED] |UNIX SIG Leader at PACS http://www.netaxs.com/~cjf |(Philadelphia Area Computer Society) ftp://ftp.netaxs.com/people/cjf|Design Science Revolutionary Dare to be Naive -- Bucky Fuller |Explorer in Universe
netpbmdevel-1994.03.01p1-1
-BEGIN PGP SIGNED MESSAGE- Date: 30 Jun 96 22:33 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson [EMAIL PROTECTED] Source: netpbmdevel Version: 1994.03.01p1-1 Binary: netpbmdevel Architecture: i386 Description: netpbmdevel: Netpbm development libraries and header files. Changes: First upload. This is a split-off from netpbm proper. -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMdcA2Cu/XyBsR8PBAQGSGwP+OATEaPzei84nNGdPlmBmq/L9uqtL6D3Z c7lwYUIrtL1IhnBSvsk379Eo9dr9b/P+QsXmIrWCLSeG+8UDDb7Umhg5s2od7w7T 5P/66GMxq221DA7w/qfKEVt1w/7dsMfRdXzj7HxxkzIj5R7dD33csk6e5+5HFt/7 DXBc6QEjzLw= =qDpg -END PGP SIGNATURE-
Re: /etc/default? (was: Re: Bug#3368: cron's checksecurity still scans NFS servers)
You (Lars Wirzenius) wrote: Steve Greenland: Maybe some sort of config file is needed here? '/etc/checksecurity.conf'? This might be an appropriate time to start thinking again about /etc/default (under whatever name). If I remember correctly, someone told us that one of the commercial vendors (or SVR4?) has a directory /etc/default, with shell scripts that set certain variables. This is Yes yes yes. Let's do this, but we'll have to be sure we are compatible with other systems. I think the shadow package also wants /etc/default, and so does mgetty. I for one would be very happy with /etc/default/boot etc. for the init scripts! Unless ofcourse has a better proposal, which wouldn't surprise me given the neat ideas that are part of debian already ;) Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Re: Release management
On Tue, 25 Jun 1996, Scott Barker wrote: Ian Jackson said: We *must* provide a tree which contains only the most rcently bug-fixed versions of everything, and we *must not* require people to download broken packages only to have to download good ones too. ok. This is important, and I hadn't thought of it. But: yeah. i can see both sides of this issue, and am still undecided as to what i think is best. i tend towards agreeing with ian, mostly because the debian version number is IMHO completely irrelevant - our version differentiation is much more granular than that...it's the package versions which matter, not the total distribution version. however, i don't think it would be a good idea to change the way things are currently done without a lot of promotion of the the ideas behind dpkg. I talk to a lot of people about debian, and most are very happy with the improvement over their old slackware or redhat system...BUT...they haven't yet figured out what dpkg allows them to do. Debian is not just a different distribution, it's a different *type* of distribution. All other dists that i know of (with the single exception of redhat) are monolithic beasts, with little or no control over the individual software components. The packaging system (and all the thought that went into it) is debian's number 1 feature - it's even more important than the fact that debian as a whole is well designed and all the parts are generally much better integrated with each other than on other distributions. As far as I am concerned, Debian is dpkg/dselect + base. All other packages are optional plug-in modules to add various types of functionality to the base system... this is not meant to put down the efforts of all the package developers (including myself)...it's just an explanation of what i think is a good way to look at what debian is. There is no reason why we need to freeze the stuff in buzz, apart from the `1.1 must mean 1.1' idea, which has no practical benefit. It does for CD manufacturers and Consultants like myself: Client: I have a problem with my system. Me: Which version of Debian do you have? Client: Debian 1.1 Me: Yeah, but which version of Debian 1.1? What a headache. It would be better for them to be able to say: Client: I've got Debian 1.1, and I've upgraded the following packages... Client: I've got Debian 1.1, and I've upgraded the following packages... You:debian 1.1 doesn't really tell me much. Can you type: dpkg -l | mail -s versions [EMAIL PROTECTED] Client: OK. done. You:aha. i see you have foo-1.2-3. Your problem was fixed in a later version. You need to upgrade to 1.2-5. I've attached a copy to this message, save it to a file and run 'dpkg -i' on it to upgrade. You've also got old versions of the following packages list, which really should be upgraded. You can get them from ftpsite. If you're doing this sort of thing on several machines it shouldn't be too hard to write a script to be run daily from cron which mails 'dpkg -l' to a custom database program on your machine...then you will always have an up-to-date summary of what is installed on all of your clients' debian machines. Craig
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: buzz-fixed - it is essential; how do we make it ?
[ NB: I read the list. Don't CC replies to me. I pay for my PPP. Thanks ] Ian Jackson: I'm absolutely convinced that we need a `buzz-fixed' directory, to which Debian-1.1.patchlevel and stable are made to point. I'm happy if we can get one soon. I'm not sure I understood what you meant. Let me paraphrase what I think you might have meant, and you'll correct me: 1. Create buzz-fixed as a symlink copy of buzz. 2. When a package is released that must go into buzz-fixes, a symlink to it also goes to buzz-fixed. 3. Rebuild buzz-fixes/Packages and buzz-fixed/Packages. Nothing changes under buzz, right? Actually, I'm not sure we need buzz-fixes/Packages, but if we do, shouldn't it be identical to buzz-fixed/Packages? I have a slight preference to having the packages in buzz-fixes and only symlinks in buzz-fixed (remember: buzz-fixed is initially just a symlink copy of buzz), but I don't really care either way. If I'm completely wrong, just say so. I'm hazy on how all this works in practice. If I'm right, I don't think I have anything to complain about, except that the name difference buzz-fixes and buzz-fixed is too small; perhaps buzz-fixes and buzz-better would be better names? (I think we already have buzz-fixes, although my mirror is still downloading.) Comments - especially from the members of [EMAIL PROTECTED] - are welcome. Oops, sorry. :) pgp1HdTGd7MgW.pgp Description: PGP signature
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.
Re: Source packaging - alternatives
Ian Jackson [EMAIL PROTECTED] writes: are no differences that diff can't handle (deleted files, retargeted links, c). I don't know if retargeted links covers the following situation, but don't forget about dangling symbolic links. The GIMP upstream source contains links to a binaries which don't exist until you build the package. This does not make diff happy. I got around the problem by just deleting the links in the upstream source before running diff, but this is not really ideal. -- Rob
Re: kernel-source and kernel-headers packages
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian The /usr/src/linux symlink is no longer necessary for anything Ian very much, and in any case it seems to me that having the Ian most-recently-unpacked thing alway set this link to itself is Ian bad. Umm, I could not think of another scheme that was better ;-), and I think it works for most people most of the time. Ian But really the main problem is that a .deb package is a Ian stunningly bad way of distributing source code - it's exactly the Ian kind of thing that dpkg (and indeed almost any package management Ian scheme for binary packages) will have huge trouble with, because Ian people will always be editing it, compiling it, rm -rf'ing it, Ian c. Well, yes, but .deb packages are how we distribute packaged products to the debian users (most methods of delivering such products to the end-user are focussed on .deb format (dftp, dpkg-ftp, and cdrom distributors)), so if Debian is to provide the sources, it should be in this form (I dislike to think that there is a special case made for the kernel sources). I think that there is a demand for kernel sources, and that we should satisfy this need, if only for completeness. Also, though there are not now, but there may be, in the future, packages that really depend on the kernel sources; and the .deb file defines a standard place to find kernel sources on a Debian system Methinks, Ian, you underestimate your creation, dpkg handles the sources well enough in most of the cases. So far, I have no complaint about dpkg's handling of the sources, indeed, people savvy enough to edit kernel sources are usually savvy enough to understand why dpkg is complaining about extra files while deleting the source package (indeed, one may edit the sources almost at will, with no ill effect, only adding files seems to discomfit dpkg). manoj -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 [EMAIL PROTECTED] URL:http://www.pilgrim.umass.edu/%7Esrivasta/
Re: Source packaging - alternatives
Hi, Sometimes a diff file alone is not enough to change the original sources to the debianized sources, permissions on debian.rules is one that has been noted. I remember interim unofficial version of perl being distributed as shell scripts that performed a few actions (deleting/renaming files, etc), unshared to the [atch file, and applied the patch. Could this be useful? The dsc file could contain the information just as Ian proposed, but say % ./package.dsc to generate the debian sources (with proper permissions for debian.rules) from the orig and diff files automatically. manoj -- Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 [EMAIL PROTECTED] URL:http://www.pilgrim.umass.edu/%7Esrivasta/
Re: netpbmdevel-1994.03.01p1-1
In message [EMAIL PROTECTED] you write: | |-BEGIN PGP SIGNED MESSAGE- | |Date: 30 Jun 96 22:33 UT |Format: 1.5 |Distribution: unstable |Priority: Low |Maintainer: Jim Robinson [EMAIL PROTECTED] |Source: netpbmdevel Wouldn't it be more conformant to call this package netpbm-dev? I think it makes things a little more readable. (Just to keep in line with the libs, for instance) Cheers, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL [EMAIL PROTECTED] | -- Anonymous
Re: debian.rules.in and autoconf
Hi, I do not want to get into a my-conf-system-is-better-than-yours flamewar, but .. Mark == Mark Eichin [EMAIL PROTECTED] writes: Mark Actually, one of these days I *might* just port the perl build Mark process to use autoconf. Perl metaconfig/Configure asks a lot of Mark questions to which (1) it already knows the answer (2) the user Mark *won't* know the answer... The perl Configure may be made as quiet as autoconf is, and as non-interactive, if you wish, at runtime. The option of asking the user remains, and at time the user *does* know better. The verbosity is a matter of taste. I prefer to be informed of what is going on, and am not intimidated by the complexity, and I like the flexibility of a sytem that allows me to pander my curiosity and paronia ;-). Mark Most perl builds I do I use the gnu-style configure anyhow, so Mark it doesn't matter much. But yes, I think perl would be *better Mark off* using autoconf. _Mark_ I believe that the ``gnu-style configure'' is just some options to Configure, which then tries to emulate autoconf. I think that metaconfig's Configure scripts are more powerful that aoutoconf, but that is merely an opinion. I also find it easier to write modules to extend metaconfig, but that could be a matter of taste. All I suggested was that we not dismiss metaconfig out of hand. manoj -- The way to avoid the imputation of impudence is not to be ashamed of what we do, but never to do what we ought to be ashamed of. -- Tully Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 [EMAIL PROTECTED] URL:http://www.pilgrim.umass.edu/%7Esrivasta/
Automatic mount of cdroms
Good night folks, normally cdrom drives are marked with `noauto' in the /etc/fstab file to provide a smooth booting process. Does Debian provide a tool that regularily tries to mount the cdrom drive? If not, I would be happy to contribute with one and its manpage. I'm not sure to which package it then should belong. The cron package? Another base package? A package of it's own? I won't do that, just ad an option to one of the base packages. Have a nice sleep, Joey -- / Martin Schulze * Debian Linux Maintainer * [EMAIL PROTECTED] / / http://www.debian.org/ http://home.pages.de/~joey/
Uploading sysklogd 0.0-0 ()
-- Begin Changes -- -- End Changes -- PS: As usual first in ftp.infodrom.north.de in /pub/people/joey/debian/ -- / Martin Schulze * Debian Linux Maintainer * [EMAIL PROTECTED] / / http://www.debian.org/ http://www.infodrom.north.de/~joey/ / Never trust an operating system you don't have sources for! /
