Re: looking for nco maintainer Brain Mays
Rorik Peterson <[EMAIL PROTECTED]> wrote: > I am one of the upstream developers of the nco package. We have > been unable to contact via email the maintainer Brian Mays after > several attempts beginning 2003/03/03, although db.debian.org reports > activity as recent 2003/08/13. We would greatly like to update > the unstable source since many improvements (in my mind) have been > made since the last upload in October, 2002. If Brian is MIA, or > no longer interested in maintaining the nco package, I'd personally > be interested in adopting it if no one else is (although I'm not > currently a debian maintainer). I am not quite MIA, but I do have quite a few things going on in my life since this spring. Finishing a PhD, moving, and starting a new job take up quite a bit of one's time, and while I typically can make minor improvements to packages without much difficulty, I haven't been able to spare the time -- which most likely would require a couple of days -- to update the NCO packages. Right now, I have several other Debian packages that need changes, I need to write at least two papers for publication in the Journal of Computational Physics, and I am settling down into my new job. Since only one of these activities results in my rent being paid, it receives the highest priority. The others will be done when I have time. The main problem in the past year or so is that the upstream maintainers totally changed the way in which the upstream code is distributed (i.e., they moved away from the usual ftp site where I was downloading the source) without telling anyone. Therefore, I was unaware that ongoing development was occurring upstream until I receive an email out of the blue in March. (Sorry, but I don't have the time to scan Google periodically for NCO to find where the source code has gone.) Note that even the NCO sourceforge website lists the location of the upstream sources incorrectly. Thus, I receive an email informing me of all sorts of upstream development and pointing out that the Debian package is out of date. That in itself would not be a problem, but the message also included a fairly detailed list of changes in the way the code is built, including a special "debian" directory provided in the upstream source. This immediately signaled to me that significant work (more than a day) will be required to incorporate these changes into the current Debian package. These "improvements" will need to be carefully read, digested, understood, and modified to produce a quality result. Too many times, I have seen well-meaning, but not entirely competent, developers take a stab at doing their own version of a Debian package, and the results often require extensive effort to work around their code so that one can produce a real, quality package. I'm sorry, but the job used upstream to "debianize" NCO just looks sloppy to me, and they would have received a faster response from me if they had left well enough alone. Thus, the situation is as follows. If someone can point me to an new upstream source that is fairly similar to the source in the current Debian package, then I can incorporate these changes into Debian in a very short time. If, however, the upstream source contains "significant improvements" to the way the software is built (i.e., it has extensive changes), then don't expect anything from me before the middle of September. Respectfully, - Brian
Re: Technical Committee: decision on #119517?
Jamie Wilkinson wrote: > As Brian has made it clear that he does not wish to follow either > suggestion made by Dale Scheetz (splitting the package or changing the > Depends:) to ensure all executables supplied in the package run as > expected, ... While I have stated that I do not like the idea of splitting the package, I would like to avoid speculating on the specific course of action I would take should changes be found necessary. For what it is worth, I have not asked the Technical Committee for a specific solution; rather, I have asked them to rule on whether the package, as it stands, is in violation of policy. Branden thinks it is, I think it is not. Each of us can find other Debian developers who share his point of view. Since nobody in authority has informed me that my package is in violation of policy, I have assumed that it is okay as is and the matter has been decided by a "failure to rule" on the request. Certainly, some sort of time limit should be established for making these decisions. Otherwise, the debate and discussion drags on and on, without end. Personally, I have better things to do with my time than rehash my arguments, all of which I have stated several times on the lists already. - Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pcmcia-modules in woody
Lauri Tischler <[EMAIL PROTECTED]> wrote: > pcmcia-modules for kernels 2.19 and 2.20 dont exist. A set of pcmcia-modules-2.2.20 packages do exist. I uploaded a new set of these packages yesterday to sid. As for the packages in woody, I have no control over that. I wish the archive maintainers would replace the outdated packages in woody, but they never do. If you would like to help, file bugs against "ftp.debian.org" asking them to move the newer packages into woody. If anyone knows how to get packages into woody, please let me know. It's a complete mystery to me. [EMAIL PROTECTED] (martin f krafft) replied: > pcmcia-modules have, AFAIK, been discontinued. these days, you have > to get pcmcia-source and kernel-source, and compile them yourself. > it's actually a real pain, but with the variety and sheer number > of kernel-images, it would be impossible to keep up to date on all > *-modules packages. it seems that alsa-modules is still doing that > though. The pcmcia-modules packages have not been discontinued. I continue to build packages to accompany the latest kernel-image packages for the 2.2 and 2.4 series kernels. This means that I have built six packages for the 2.2.20 kernels and one for the 2.4.17 kernel using the latest version of pcmcia-cs. I have neither the time nor the resources, however, to build packages for all of the kernel-image packages out there (last time I counted there were 27 of these packages). Anyone willing to build these packages is welcome to do so. I have tried to automate and document the procedure as much as possible, and I am willing to provide advice and assistance to anyone willing to try. Fortunately, some of the maintainers of the kernel-image packages are nice enough to also build a new pcmcia-modules package to accompany a new version of their packages. That certainly helps. - Brian
Re: Problem with pcmcia-modules and kernel-image
> Sure ? Actually pcmcia-modules-2.2.18 depends on kernel-image-2.2.18... The pcmcia-modules-2.2.18 package shipped with Debian depends on kernel-image-2.2.18, but pcmcia-modules packages in general -- e.g., those built locally by users to accompany their custom kernels --- do not have this dependency. Such an assumption would be imperfect, at best. I still think that this should be the job of the kernel maintainer, not the PCMCIA package. - Brian
Re: Problem with pcmcia-modules and kernel-image
Raphael Hertzog <[EMAIL PROTECTED]> wrote: > i'm running unstable and i can't get pcmcia-modules-2.2.18 to work > with kernel-image-2.2.18. I always get unresolved symbols (script log > attached). And I had the same problem with 2.2.18pre21 but 2.2.17 is > ok. I didn't report it for 2.2.18pre21 because I thought that this was > a temporary problem but since it's still here i'm wondering what's > going on ... am i the only one having unresolved symbol ? No. There is already an open bug report for this problem (see Bug#80301). > ... After looking at the BTS, I learned about a possible > incompatibility because one was compiled with gcc 2.95 and the other > one with gcc272 ... is that still the problem ? Hmm ... I don't know. I have gcc 2.95 installed on my system, which was used to build the pcmcia-modules-2.2.18 package. I don't know what Herbert Xu has used to build the kernel-image-2.2.18 package. He has not responded to my email regarding this problem. One thing is clear. I'm doing something different to build the PCMCIA modules than was done to build the kernel image. For example, I think that you can get Debian's PCMCIA modules to work if you rebuild the kernel-image package yourself. At least, I've had no trouble building PCMCIA modules against kernel images that I have built myself, only against the official Debian kernel. > PS: BTW, each time when I boot a new kernel there's a loop because > modules.dep doesn't exist ... I don't know who is responsible to > generate this file but pcmcia-modules should call it for sure ... and > actually the postint does call depmod -a only if the current kernel is > the one for which the modules have been compiled, shouldn't it call > depmod -a instead ? Well, that only works if the appropriate kernel version has already been installed, something that the pcmcia-modules package cannot ensure. Certainly, I can guarantee that the currently running kernel is installed; therefore, I call "depmod -a" if the modules match this kernel. If the modules accompany another kernel, then the system will need to be rebooted to use the kernel in question. Therefore, I think that it should be the kernel package's responsibility to ensure that the dependencies have been created. If you have any creative ideas to better handle this problem, please share them. - Brian
Re: X and runlevels
> On 04 Sep 2000, Brian Mays <[EMAIL PROTECTED]> wrote: > > Not quite. The FHS briefly mentions *System V's* runlevel 2 and > > 3 (along with Berkley's multiuser state). It does not specify > > anything about runlevels for Linux or any other OS. Gerfried Fuchs <[EMAIL PROTECTED]> replied: > O.k., you're right - it was on linuxbase.org. Which we support, > according to their main-page. ... So, I'm asking, why we don't follow > this guidelines? Hmm ... Have you actually read the "Linux Standard Base Specification"? There's not much there; they have hardly fleshed out any of the specification. Personally, I hope that the impact of the whole LSB project on Debian will be a few minor changes and that most of the facilities required to be LSB compatible can be supplied by a single "lsb" Debian package. That is a long way down the road, however. > I don't see any contradiction with our current approach to leave it up > to the user. That won't interfere IMHO, for the update-rc script (or > what ever it's called) doesn't touch the links if any of them exists, > right? So the user can still change 'em to her/his likes. Go ahead and make a proposal that we adopt a particular runlevel scheme. Then the developers can vote on it. It is true that the update-rc script will still allow the system administrator to customize the links to his or her own needs. > Now, are we part of the linuxbase-project or aren't we? I know that > it's not good to take everything without asking it - but the current > setup is somewhat nonsense to me - 4 runlevels with the same setup Not really. Some of our members are providing input into the project, but the LSB project doesn't have enough of a standard yet to adhere to, even if we wanted to adhere to it. - Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
> On 04 Sep 2000, Ethan Benson <[EMAIL PROTECTED]> wrote: > > also debian believes in leaving the runlevel configuration to the > > admin to define. [EMAIL PROTECTED] (Gerfried Fuchs) wrote: > Sure - but there is the FHS (I hope that I read it there) that > defines what at least runlevel 2 and 3 are for. I would really > like to see that Debian complies with the FHS in that case, when it > complies to it in the other meanings also, quite strict, even. Not quite. The FHS briefly mentions *System V's* runlevel 2 and 3 (along with Berkley's multiuser state). It does not specify anything about runlevels for Linux or any other OS. - Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: dvipdfm - A DVI to PDF translator
Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > But the comment says the whole story, it is compatible with standard > Adobe fonts, aka times which is what I had the problem with. Jason - You would think so. Nevertheless, try it; it works. Therefore, I must assume that the comment is incorrect. - Brian
Re: ITP: dvipdfm - A DVI to PDF translator
Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > Right now there are 4 ways to produce PDF's (AFAIK) [...] > That said, my current favorite method is to use gs 6.0's ps2pdf, my > documents all have eps figures! > > There are other problems however - ... > Another problem is that the times font (or any native postscript font for > that matter!) does seem to support ligatures! This problem is not limited > to just PDF however, postscript files output from dvips and viewed in > ghostscript show pound signs for 'fi' and other ligatures are similarly > wrong. Converting that postscript to PDF naturally propagates this error > :< The ligatures are supported, but dvips switches the characters in the font around. This can be fixed by turning off the "G" option in the /etc/texmf/dvips/config.pdf file. % Character shifting. You want to do this using the BlueSky/AMS/Y&Y fonts. % It remaps certain ``control character'' positions to an another range % where these characters are repeated. This option is compatible (and will % have no effect on) standard Adobe or other Type 1 fonts that do not use % to problematic positions. It is INCOMPATIBLE with any fonts that use % these control character positions but that DO NOT repeat them in the % exact same way as the BlueSky/... fonts. I don't know of any, but I % haven't even tested this with BaKoMa fonts. %G - Brian
Re: Danger Will Robinson! Danger! (PCMCIA anyone?)
> On Sat, Mar 11, 2000 at 11:44:39PM -0600, Manoj Srivastava wrote: > > Why is it bad having a stable kernel installed as default, > > and a 2.4-pre kernel, marked as extra, with warning in the long > > description, also in the distribution? [EMAIL PROTECTED] (Marcus Brinkmann) added: > Nothing wrong about that, if we don't go a long way to make additional > changes in the various admin packages (isdn, pcmcia comes to mind). Marcus is correct and has touched on something that most of those calling for the "latest and greatest" kernel haven't considered. It is easy for them to emphatically demand the latest version of the kernel, since they do not have to do the work or deal with the consequences, but there are several additional points that need to be addressed. The one that concerns me personally (as the PCMCIA maintainer) is whether we shall also provide PCMCIA support for this kernel. I can tell you from experience that PCMCIA support lags kernel development. Therefore, support for a new kernel will not be available until the next upstream release (at the earliest). This in itself creates problems, since this new release will be several releases beyond the current packages in potato and new releases do often break things, as the bug logs for pcmcia-cs demonstrate. This problem is not simple enough that it is possible to merely build a new pcmcia-modules-2.4-pre package. Since all of the pcmcia-modules package depend on a pcmcia-cs package with the same upstream version number, upgrading the version of one of the pcmcia-modules packages requires that ALL of the pcmcia-modules and pcmcia-cs packages must be upgraded to maintain compatibility. I would like to avoid what has been done in slink, where someone (Vincent Renardias <[EMAIL PROTECTED]>) did a NMU of a new pcmcia-modules package and broke the dependencies of all of the other PCMCIA packages. This is particularly annoying for me, since I was not consulted before this NMU was done (which is too bad, since I am a helpful maintainer -- just ask anyone who has worked with me on rxvt -- and could have warned him of this problem). By the way, this still needs to be fixed. Is anyone willing to rebuild the PCMCIA packages for slink to fix this problem? Please. I'll end with my main question: what is to be done about PCMCIA support for this new proposed kernel package? Brian
Re: Too many kernels in unstable
John Lapeyre <[EMAIL PROTECTED]> wrote: > In another thread, I am dealing with exactly this problem. My > machine hangs with 2.0.37 and 2.2.x, but is OK with 2.0.36. But had > to take a piece of driver code from 2.0.37. There are quite a few new > issues arising from two gcc branches and two stable kernel branches. I understand. I tried installing 2.2.12 on my laptop and noticed that I was having trouble with the APM support. Therefore, I returned to the 2.2.10 version. >Having a few kernels around gives some flexibility in trying to > put together a working system. 11 kernels is probably too much, but > a couple of each might be OK. We (someone !) could also package the > patches, which is a bit more of a pain for the user, but we could get > all 12 new kernels without adding so much bulk to the archive. I could definitely live with this. I wouldn't need to build PCMCIA modules for patches. On a side note, years ago (when I had a smaller laptop), I used to use patches quite frequently to get the PCMCIA modules built for the various kernels provided by Debian. This worked, for the most part, but I eventually abandoned this technique when I started to have problems building modules that were truly compatible with the kernels. Building kernel modules is a tricky business; extra care taken from the beginning saves much time later rebuilding. Brian
Re: Too many kernels in unstable
> [EMAIL PROTECTED] (Brian Mays) writes: >> Once 2.2.12 makes it out of Incoming, we will have 8 kernel >> versions in the unstable distribution? Do we REALLY need to >> provide that many versions of the kernel?? >>>>> "Guy" == Guy Maor <[EMAIL PROTECTED]> writes: > What about just keeping the last 2.0.x and the last 2.2.x ? That would be fine by me; however, some people might object because kernel "improvements" sometimes break things -- even in stable kernel branches. It is not so rare for someone to avoid upgrading to the next kernel version, because it breaks some obscure feature that he needs. Perhaps we should keep the last two versions of each branch? In this case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I don't know. Let's see whether anyone objects to just keeping two versions around. > It's also a lot of space on the ftp site. It's a lot of space on my laptop too... (93M to be precise) Brian
Too many kernels in unstable
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? I hate to complain, but every time a new version of the PCMCIA modules is released, I have to build a set of packages for EACH of these kernels. It's starting to become a real pain in the ass. Can't we keep the number down to something more manageable, say 4 at most? Brian
Developer's version of rxvt available
Since the last "official" release of rxvt is so old and out-of-date (it is a year and a half old), I have released the latest developer's version of rxvt in a new package, called rxvt-beta. Rxvt users, please help me test this package. It currently works with the new pty scheme and utmp/wtmp formats. Thanks, Brian
Re: Intent to package wterm
> Adam Klein wrote: >> Oh, fro the rxvt package? hmm. Do I need to incorporate those? Marcelo E. Magallon wrote: > Well, they are there for a reason, aren't they? Some of the patches will not need to be added, unless you are also planning to make a Kanji, Greek, or Chinese version of wterm. Brian
Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)
Joey Hess wrote: > > I think it's not necessary that a developer agree with the DFSG. It > > should be enough that they indicate they understand it and will > > abide by it in what they produce for debian. Then, Chris Waters <[EMAIL PROTECTED]> wrote: > Yes, but OTOH, it's a little hard to fathom why someone would *want* > to work on Debian if they didn't agree with at least the basic > outlines of the DFSG and the Social Contract Of course, you're both right. Therefore, we should require that developers understand and abide by the DFSG, and let the rest take care of itself. Brian
Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)
I ([EMAIL PROTECTED]) wrote: > > With all due respect, if you think that there is no diversity of > > opinion in Debian, then you haven't been around here for very long. [EMAIL PROTECTED] (Ossama Othman) responded: > I was referring to the fact that many of the developers strongly felt > that I should agree with the DFSG, i.e. not have my own opinion of it. > So, with all due respect, please don't understand me so fast. :) I was merely trying to point out that we have flame wars ... ahem ... disagreements on these lists all of the time. I just wanted you to know that you are far from the only person who has made a suggestion and received several negative responses. It happens all of the time. Please don't get the impression, however, that we always reject new ideas. Often a suggestion receives an enthusiastic response. Whether anything changes (i.e., whether someone does the work to implement a new proposal) is another matter. ... > I was not referring specifically to Craig. Rather I was referring to > some of the statements that were made by several developers about "if > you don't agree then you should consider leaving" or something along > those lines. If I gave you the impression that I was singling out or > attacking Craig then I apologize for that. I do admit that it is hard > to keep calm when everyone seems to disagree with you. So, if I came > off as attacking Craig then please excuse me. There is really no need to apologize. However, it is my experience that almost all of these type of suggestions are (at least) in the spirit of: "This is how many of us feel, and if you are uncomfortable with this, then perhaps you would feel more comfortable with some of the other groups that currently exist." I have rarely seen examples of anyone trying for force someone out of the group, and of those situations where it does come across this way, I believe that it is almost always a case of the author becoming carried away an overly heated argument rather than an actual sincere attempt to force anyone out. > I agree with you about understanding and complying with Debian's goals, > which is why I abide by them. ... and is why I said "I'm sure that you will agree" (with me not necessarily the DFSG). > But, does that mean that I have to agree with them? Of course not! We don't want robots. We want individuals who are willing to work towards a common goal. Anything constructive that you bring to the project is welcome. However, you should realize that an endevor like this, which is a labor of love, inspires strong passions and ideals, and these are some of the things that you will encounter when you deal with other members of the Debian project. > I do truly try to respond in a calm fashion, although I don't always > succeed. Don't worry. Nobody expects you to be perfect. Besides, you were polite, which is something that is always more than welcome on the Internet. Discussion, even of the same old things, is a good thing. > I didn't realize that renaming non-free was suggested before. Why didn't > anyone tell me? Think of all the headaches I could have avoided! :) I was kind of wondering the same thing myself. Brian
Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)
[EMAIL PROTECTED] (Ossama Othman) wrote: > If used properly, diversity of opinion should only help Debian. With all due respect, if you think that there is no diversity of opinion in Debian, then you haven't been around here for very long. > Those with opinions that differ from the mainstream should not be > branded "heretics" or encouraged to leave. Now, play fair. I was under the impression that Craig's statements were merely a friendly suggestion and not meant to pressure anyone out of the project. Of course, nobody is requiring every member to surrender his or her opinions. However, I'm sure that you will agree, requiring our members to understand and comply with Debian's goals, motivation, and policy are essential if we are to accomplish anything as a group. Besides, is it fair to label opinions that happen to agree with the mainstream as "elitist?" I'll admit that sometimes certain individuals may be overly curt, but I think that this comes from having to debate the same things over and over. (I myself can recall twice before when someone has suggested that we rename non-free, but of course, I could have missed a few of these discussions.) These things do get old after awhile. Brian
Re: non-free --> non-dfsg
[EMAIL PROTECTED] (Joey Hess) wrote: > Hm, non-debian does have its good points. It has some potential problems, too. It could imply that the packages found there are not built by Debian volunteers, or that they do not adhere to Debian's policy standards, or that they are not supported by Debian's bug tracking system, all of which are false. Finally, I find non-debian-free to be redundant. This is a subdirectory of the Debian's site. Therefore, non-free immediately implies non-debian-free. Brian
Re: xterm-debian terminfo entry
[EMAIL PROTECTED] (Alexander E. Apke) wrote: > Now that debian is going to be using a nonstandard terminfo entry > for xterms, can the default colors be setup like a normal linux console, > black background with white foreground. > I liked this when the xterm was setup this way a while back. I > believe the reason for switching back to white background was for > compatibility sake. Since xterm-debian is the standard terminfo entry > for debian, a black background would also be nice. > The black background is much more pleasing to the eye, especially > with colors enabled. This does not need to be done with at terminfo entry. Use the following X resources (in either $HOME/.Xresources or /etc/X11/Xresources for everybody): XTerm*background: black XTerm*foreground: gray90 By the way, this also will cause rxvt windows to use reverse video. Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package xruskb and netenv
I intend to package two new debs: xruskb and netenv. Package: xruskb Version: 1.5.3-1 Description: An X localized keyboard switch and autolock. Xrus is a utility for switching the keyboard mode between different layouts. While it is intended for switching between latin and russian keyboards (RUS/LAT), xrus can be configured to use any two layouts provided that the proper modmaps have been loaded. Xrus monitors all keyboard and mouse events, and when a particular hot key combination is pressed, it swaps 1,2 and 3,4 columns of the keyboard map. When a a specified time period without keyboard and mouse events passes, it starts a locking program. This package also contains several Cyrillic keyboard mapping tables. Package: netenv Version: 0.81-1 Description: Configure your system for different network environments. Netenv creates a file containing variable assignments which reflect the current environment. It is especially useful for laptop computers, since it can be used by the PCMCIA setup scheme (like the one included in the Debian pcmcia-cs package) and the plip setup script included as an example in this package. You can also use netenv configure your windowmanager or your printing environment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anyone want to make a Debian XDM login screen?
[EMAIL PROTECTED] (David A. van Leeuwen) wrote: > I'd opt for a `shutdown' button on the XDM login screen. > Right now there isn't a simple way of bringing the machine down---as > far as i know. Even ctrl-alt-del doesn't work in XFree86. > Of course, care should be taken that this can be done only from the > console---if necessary, only after typing a shutdown password. There is an easy way to get this button on your screen, assuming that you have the TCL/TK packages installed. Add the following seven lines to /etc/X11/xdm/Xsetup_0: /usr/bin/wish < /var/run/xdmbutton.pid and add the following line to /etc/X11/xdm/Xstartup_0: if test -r /var/run/xdmbutton.pid; then kill `cat /var/run/xdmbutton.pid`; fi This will pop up two buttons in the lower left corner of your screen. The "Halt" button will shut down your system, while the "Reboot" button will reboot (useful if you also have Windows 95 *yuck* on your computer). In my opinion, this is much more useful than Ctrl-Alt-Delete. Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anyone working on new rxvt version?
Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > If these copyright issues are still relevant - you will find the email > of the xvt author about changing the copyright to gpl in the kdebase > copyright file (because kdebase include kvt, and this way xvt code). The new upstream maintainers must be aware of this copyright change because the latest stable rxvt release is under the GPL. Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Anyone working on new rxvt version?
Paul Slootman <[EMAIL PROTECTED]> writes: > rxvt 2.4.5 was announced on New Year's Day. As the current hamm package of > rxvt is still 2.20, it would be great if the new version is available. > There have been many improvements; I notice the difference immediately > when I happen to use 2.20 instead of the 2.4.x versions. Of course. I, the Debian maintainer of rxvt, am packaging the new version. Actually, I've already assembled the package. I am currently testing it, so it should be uploaded sometime this week when I'm satisfied that I have worked out most of the quirks. Brian -- Deadwood, n.: Anyone in your company who is more senior than you are. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Yann Dirson <[EMAIL PROTECTED]> writes:
> Adam P. Harris writes:
> > I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
> > 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
> >
> > This would allow, for instance, MTA packages to ship little scripts to
> > flush the mail queue when the link comes up, pop-deamons to start up,
>
> I had the idea of adding such actions (flush mailqueue, fetch mail,
> etc.) to my ip-up, but I didn't do that.
>
> This is because some of these actions (eg. mail fetching) may be quite
> long to complete, and may act badly if interrupted by a 'poff'
> (eg. fetched messages from the interrupted session not erased from my
> POP account - guess it's a security feature in fetchmail).
>
> The solution I used was to manually ask to fetch my mail. Another
> would be to have a (hopefully generic) mean of forcing the line to
> stay up while such an action is taking place. But I'm not sure it
> would be a good solution either, since fetching 200 mails/day from the
> debian lists takes some time, and then the user would be compelled to
> want till fetch is done.
>
> In other words:
>
> * we can't decide for the sysadmin what actions will take place on
> boot.
>
> * if we build such a system, a standard way of disabling parts of
> these directories (maybe like what /etc/init.d/rc allows with 'S' and
> 'K' names ?)
Yes. Definitely ensure that it is easy to disable (and of course
re-enable) these automatic scripts, and ship everything _off_ by default.
IMO nothing is more annoying than these kind of surprises. I want to
know what is being started when I dial into my ISP.
For example, I have configured my ip-up script to start fetchmail (in
daemon mode) and grab articles for my local news spool unless the file
/etc/no_mail exists. Therefore, if I need to quickly dial in, say to
fetch a file, I create this file before starting pppd so that I can
hang up as soon as I am done without waiting for POP and NNTP transfers
to finish.
Brian
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
>>>>> Brian Mays wrote: >> This is the rxvt maintainer here. Rxvt has many optional >> compile-time features, one of which is the behavior of the >> backspace key. Normally, I avoid modifying as many of the >> "upstream" settings as possible, unless someone gives me a >> valid reason to change them. >> >> Currently, rxvt sets the backspace key by "using the current >> stty setting of erase to guess a Backspace value of either ^H >> or ^?." I can change a compile-time option to force rxvt to us >> ^H always for backspace. Is this useful? >>>>> Galen Hazelwood writes: > Well, it would free me from having to make a quick new release > of ncurses, so I think it would be useful. People seem to have > found a workaround, but I think it's better to have it set right > to begin with... Okay. I'm building a new unstable version of rxvt with backspace set to ^H. From this point on, Debian's rxvt policy will be to use ^H as backspace by default. Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Unresolved symbols with ibmtr_cs PCMCIA module
Stephen Zander <[EMAIL PROTECTED]> writes: > Further in my attempts to setup up a Thinkpad 760CD... > > When attempting to load the ibmtr_cs.o mdules under the standard > 2.0.30 kernel, I get the folliowing unresolved symbols. > > netif_rx_R9117ffb8 > dev_alloc_skb_R24e337ab > dev_kfree_skb_R7a61ae71 > dev_tint_Rcc72f6b2 > unregister_netdev_Re5a9d51a > register_netdev_R70caa700 > tr_setup_R787bcf6f > tr_type_trans_Rf1130552 > > Should I load another module to resolve these or is there > something else I'm missing? This is caused by an incompatibility between the pcmcia modules and the kernel's configuration. I've created new packages that fix this problem (pcmcia-cs and pcmcia-modules-2.0.30-7, both version 2.9.6-1) that currently are waiting to be included in the distribution. I am sorry for the inconvenience. If anyone needs these packages now, before they can be included into the distribution, send me a message and I can e-mail them using either MIME encoding or uuencode. Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
>>>>> "John" == John Goerzen <[EMAIL PROTECTED]> writes: John> X11 mouse support is something that is important to me John> personally. Home and end keys aren't that important since John> most apps don't handle them correctly anyway. Well, since rxvt's special features are important enough, I'll have rxvt set TERM=rxvt for color displays and TERM=rxvt-mono for monochrome displays. I'll contact the maintainer of the ncurses-base package and ask him to add an rxvt-mono terminfo/termcap entry. [ stuff omitted ] John> Or we could forget about trying to adapt to a B&W screen John> until such a thing happens and just set it to rxvt. After John> all, the Linux console doesn't automatically remove colors John> when not used on a color system. John> And how many people are using true monochrome graphics John> anymore anyway? AFAIK, the latest PC monitor that did that John> was the old Hercules (sp?) card used in XTs. I don't think John> XFree86 even supports that card anymore. Most of the John> non-color monitors I've seen for PCs these days are simply John> grayscale VGAs. They look like color monitors to the PC. I John> think that if we start worrying terribly about people who John> have 1-bit displays, that we are going to be doing a lot of John> unnecessary hacks to the system. Remember, we're talking John> about a display here that cannot even do bolding correctly. [ stuff omitted ] John> Even standard VGA has 16 colors and would support color John> rxvt. I really have not seen a 386 or better running John> anything older than VGA, and VGA (or SVGA) always has at John> least 16 colors available. In fact, do we even have any John> Debian users on 1-bit displays? This is a mistake. I for one have used a 1-bit display. I have a PC with a Matrox graphics card, and before XFree86 supported this type of card, I was forced to use either the generic 16 color VGA server or the monochrome server. You obviously have never used X windows on a 16 color display -- it looks horrible. I very much preferred the monochrome display. Don't knock B&W. It gets the job done and no color is often better than bad color. [ stuff omitted ] John> The standard termcap/terminfo out there (distributed by esr John> I believe) has those entries. It is not our job to take John> care of OSs with obsolete termcap and terminfo stuff. John> (There is no excuse for no xterm-color entry -- the color John> xterm has been in X for years) Don't tell me ... tell the xbase maintainer. Debian's xterm does not set TERM=xterm-color. [ stuff omitted ] >>>>> "Brian" == Brian Mays <[EMAIL PROTECTED]> writes: Brian> With this mind, rxvt will set the TERM variable to xterm or Brian> xterm-color depending on the color depth of the X display. Brian> This is the default behavior of rxvt provided by the Brian> upstream maintainers, so it should be consistent with rxvt Brian> version compiled on non-Debian Unices. John> If this is the default behavior of rxvt, how come the Debian John> version doesn't do this? I'm running in 16-bit color mode John> and it still sets it to xterm. I did not compile rxvt to set TERM=xterm-color because Debian's version of xterm does not set it. If I was incorrect, at least I was being consistent. Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
Kai Henningsen <[EMAIL PROTECTED]> writes: > One thing that I have missed in this debate so far: a lot of the > configurations relevant to this discussion should really be adjustable per > user. Ideally, yes. I guess so many of us have single-user systems that this point tends to get overlooked. > With that in mind, wasn't there some dot file generator? Could that thing > be made to do this? Now you are talking about a program to be executed by each user that lists a series of possible configurations for each application and allows the user to choose one. This truly would be the best way to make Debian newbie-friendly. Now all we need is someone to write this thing (or to find and improve this dot file generator to which you refer, if it exists). Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <[EMAIL PROTECTED]> writes:
> I see a `config package' as a package that includes/modifies other
> packages conffiles. Using packages for this is ignoring the concept of a
> package. What if you remove one of these packages? What if some programs
> whose files are modified are not installed? What if one of these programs
> is installed _after_ the config-package? Should the config-package depend
> on every progam it configures? config-packages will depend on changes in
> several packages...
I would not advocate implementing such a package this way. Most of
the config files that we would be interested in fixing for newbies can
include or source another file. Take sh-like shells for example. We
would have the /etc/profile file (that is the file provided by the
bash package) source another file (if it exists) that would be
provided by our hypothetical config-package. We can even use the
update-alternatives tool to sort out which config file will be soured
when multiple config-packages are present on a system. This is more
in line with what I was thinking.
Milan Zamazal <[EMAIL PROTECTED]> writes:
> 1. I don't know whether I like the idea of a single config package or not
> but I can see the following questions:
> - Is it easy/possible to maintain single config package for many
> programs?
I don't think that it would be too difficult. Such a configuration
package would not include configuration data that are essential for
the operation of any part of a Debian system. This package would
contain only fluff -- that is, stuff to make the system look nicer.
Making such a package would involve collecting all of the preferences
that the developer feels would be useful or pretty and packaging them
together to share with others.
> - Isn't it better to let this work to each package maintainer because
> he does probably understand it very well? I don't think there
> are many (hundreds) packages which need some kind of newbie
> customization. If I understand it well it should be about ten to
> twenty files in `/etc/skel/'.
Adding preference changes to the files in /etc/skel has been discussed
before on this mailing list. If I recall correctly, it is generally
preferred that changes be made to the system-wide configuration files
rather than the /etc/skel files (for example, /etc/profile instead of
/etc/skel/.bash_profile). However, I think you are correct, there
shouldn't be a large number of packages that need a little boost to
become newbie-friendlier.
> - On the other side wouldn't be better to let this configuration
> things to one package with one maintainer ("newbies manager"), who
> could watch newbies questions on debian.user etc. so he knows what
> the *real* problems are?
Thank you. You have just clearly stated my main argument for a
newbie-configuration package.
Finally, I feel that I should add a bit to the `rm -r *' discussion.
Wouldn't it be nice to provide newbies with the alias rm='rm -i'?
I've seen this done on the systems here at my school and on systems
where I have worked. This alias is usually defined in
/etc/skel/.profile (or some such file), so that it is present on all
new accounts. (Notice that I am talking about modifying the files in
the /etc/skel directory when I said above that this should not be
done.) This trick prevents a new user from inadvertently erasing
important files until which point he or she tires of confirming each
file deletion and learns how to edit his or her .profile to remove the
annoying alias. It's just a thought.
Brian
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
This is why changing the default prompt for everyone is not a good idea. You guys can't even agree on what you want the new prompt to be. And if you want my personal preference, any prompt longer than '$ ' is too long. If I want to know what directory I'm in, I just pwd. Instead of arguing back and forth about this new prompt, please do something constructive. Build a "Debian 4 dummies" package, which includes your favorite prompt along with all of the other nice defaults that you wish to include. Add a sentence in the package's description that says "If you are new to Debian or Linux, this package comes HIGHLY RECOMMENDED." Of course, there will be some technical details with the implementation of this package that will need to be ironed out, such as how to get PS='' into /etc/profile, but I'm sure that these will be minor. If you want to get fancy, you can also add to this package some useful scripts for configuring a Debian system that no Unix "real man" would need or want. I believe that the newbie-friendly defaults should be collected in one place and not scattered across many Debian packages. If they are in one package (or a small number of packages), it will be easier for us to define what the Debian newbie-friendly environment is and to plan what we want it to become. I especially believe that these defaults should be optional. Remember, the user should configure her system, not deconfigure it. If she must spend time and effort to rid her system of somebody else's nifty configuration, then IMO we're doing it wrong. Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
>>>>> "Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
Brian> rxvt (and rxvt-xpm) always exports the variable "COLORTERM"
Brian> so that programs can check for color support.
>>>>> "John" == John Goerzen <[EMAIL PROTECTED]> writes:
John> Unfortunately, I know of no programs that make use of this
John> variable. In fact, I believe that ncurses doesn't even use
John> it.
The rxvt authors claim that programs such as JED, slrn, Midnight
Commander check this variable. I don't know since I don't use any of
these applications.
Brian> As a side note, when XPM support has been compiled into
Brian> rxvt (as with rxvt-xpm supplied in Debian's rxvt package),
Brian> the value of COLORTERM is set to "rxvt-xpm" instead of
Brian> "rxvt".
John> Which could be a bug in itself since Debian has no rxvt-xmp
John> terminfo entry.
This is not a problem since ncurses uses the TERM variable and not the
COLORTERM variable.
John> I would suggest that rxvt set TERM to rxvt when on a color
John> display and to xterm when on a non-color display. The rxvt
John> entry in terminfo already has color support; the xterm entry
John> is monochrome. Since rxvt is backwards-compatible with
John> xterm, this would seem to be the proper method. It would
John> cause the least fuss while ensuring proper behavior in all
John> situations.
John> Even if this isn't done, I suggest that the default be set
John> to rxvt. After all, we have the terminfo entry for it, it
John> doesn't make any sense not to use it.
Observe the difference between the rxvt entry and the xterm-color
entry:
$ infocmp rxvt xterm-color
comparing rxvt to xterm-color.
comparing booleans.
comparing numbers.
comparing strings.
kend: '\EOw', '\EOe'.
khome: '\E[H', '\EO\200'.
kmous: NULL, '\E[M'.
Other than the home key, the end key, and X11 mouse support, there are
no differences between the two entries. Therefore, unless we really
care about these three features, using TERM=xterm-color is good
enough.
I think that we have two choices:
1) Strive to be totally correct:
Convince the ncurses maintainer to provide two rxvt terminfo entries:
one with color capabilities defined and one without color capability.
The rxvt program will set the TERM variable to the appropriate entry
according to the color depth of the X display.
2) Strive for compatibility:
Not all Unices have an rxvt terminfo entry. The RS6000 and SGI
machines on which I have accounts do not have an rxvt entry or an
xterm-color entry. Thus when I rlogin onto these machines from an
rxvt window, the terminal capabilities will default to those of a
"dumb" terminal because TERM=rxvt and TERM=xterm-color are unknown
terminal types to them.
With this mind, rxvt will set the TERM variable to xterm or
xterm-color depending on the color depth of the X display. This is
the default behavior of rxvt provided by the upstream maintainers,
so it should be consistent with rxvt version compiled on non-Debian
Unices.
Users who insist on using the rxvt terminfo entry can monitor the
COLORTERM variable. For example, they can place the following in
their .profile file:
TERM=${COLORTERM:-$TERM}
What I want to avoid is TERM=rxvt on color displays and TERM=xterm on
mono displays. I can see this leading to bug reports when the HOME
and END keys work on color displays but fail to behave the same way on
mono displays. For consistency sake, these keys should either always
work or always not work.
John> I suspect that rxvt would behave properly in this case even
John> if it is on a 1-bit (B&W) display.
The problem is not whether rxvt does the right thing, we need to
ensure that the programs running in an rxvt terminal do the right
thing. This means that when rxvt's window is located on a monochrome
display, the programs running on that window should know that they are
on a terminal that does not have the capability to display colors.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
>From the original bug report by John Goerzen <[EMAIL PROTECTED]>: > rxvt-xpm, at least, is setting TERM to be xterm. It should be set to > "rxvt". Debian's termcap/terminfo (as well as that of every other Linux and > many other modern OSs as well) has an rxvt entry, and it should be used in > this situation. rxvt (and rxvt-xpm) always exports the variable "COLORTERM" so that programs can check for color support. As a side note, when XPM support has been compiled into rxvt (as with rxvt-xpm supplied in Debian's rxvt package), the value of COLORTERM is set to "rxvt-xpm" instead of "rxvt". > If for some reason that is not possible, at a minimum, xterm-color should be > used. Otherwise, programs fail to recognize the color capabilities of rxvt > and do not display in the best manner possible. Note that xterm from xbase version 3.2 sets TERM to xterm, and not xterm-color, when color support has been enabled. Perhaps the following line should be added to /usr/lib/X11/app-defaults/XTerm-color: *VT100*termName: xterm-color I can rebuild rxvt to set TERM=xterm-color (there are not many differences between the terminfo entries for rxvt and xterm-color). However, if we are to do things absolutely the correct way, I suppose that Debian should provide a "rxvt" terminfo entry and a "rxvt-color" entry (with color support as the only difference between the two). Then rxvt would set TERM=rxvt-color when running on a display with Xdepth > 2 and TERM=rxvt otherwise. Does anyone have any thoughts on this? Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Bug#4574: gs -g flag does not work
Package: gs Version: 4.01-4 The `-g' flag, which is described below, does not produce the intended effect. >From the man page: > -gnumber1xnumber2 > Equivalent to -dDEVICEWIDTH=number1 and -dDEVICE- > HEIGHT=number2. This is for the benefit of devices > (such as X11 windows) that require (or allow) width > and height to be specified. For example, under X11 windows, the commands $ gs -g100x100 some_postscript_file.ps $ gs -dDEVICEWIDTH=100 -dDEVICEHEIGHT=100 some_postscript_file.ps $ gs some_postscript_file.ps all produce the same results. Note that this is independent of the contents of the `/etc/papersize' file (including when this file does not exist).
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: ... -u directory with files (default is `..')
Re: Checking on possible bug in mt...
> Rob Browning writes: Rob> I'm trying to decide if this is a bug in mt, or my relative Rob> inexperience with tape drives. If it's a bug I'll report it, Rob> and it'll probably have to go to the upstream maintainers. Rob> # mt --file /dev/nst0 tell Rob> mt: /dev/nst0: Function not implemented Rob> Any idea why? Well, all that mt does is call `ioctl (desc, MTIOCTOP, &position)'. >From this function, a `-1' is returned to mt, thereby signaling an error, and errno is set, by ioctl, to the code for a `Function not implemented' error. If there is a problem, it is probably with the Linux SCSI tape driver. -- Brian
maplay_1.2-1 uploaded
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Fri, 23 Aug 1996 22:51:53 -0400 Source: maplay Binary: maplay Architecture: source i386 Version: 1.2-1 Distribution: unstable Urgency: low Maintainer: Brian Mays <[EMAIL PROTECTED]> Description: maplay - An MPEG Audio Player. Changes: maplay (1.2-1) unstable; urgency=low . * Initial release. Files: e533790dfb156db973223108c561dd30 588 sound optional maplay_1.2-1.dsc f22597f9750b348801bfa3e9547f84e3 48025 sound optional maplay_1.2.orig.tar.gz eaf5a090bc22e94710a578d94381ce7a 2801 sound optional maplay_1.2-1.diff.gz aa12d0fbaca6f0e51d800cfb0b37357c 42984 sound optional maplay_1.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMiSCVPrhbOLeJ39FAQEmOgP/V6fThrjXYNgxwEfKs11YR1+UWv+navu+ fdOANiFT64OirBBi/2KDC9fa2SM1VQ+hotmuqiJd4vUVKeVUSgAuqIsaaeRgh5AQ gDd3H6bio4IG1Yu/h+yZIdimn3TeNGi25tDERc2YJzNopfi6lD8QrNsPJ4y8jrTP Fuezkgmkkzk= =o6Sp -END PGP SIGNATURE-
netcdf-perl_1.1-1 uploaded
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 24 Aug 1996 08:07:03 -0400 Source: netcdf-perl Binary: netcdf-perl Architecture: source i386 Version: 1.1-1 Distribution: unstable Urgency: low Maintainer: Brian Mays <[EMAIL PROTECTED]> Description: netcdf-perl - A perl extension for accessing netCDF datasets. Changes: netcdf-perl (1.1-1) unstable; urgency=low . * Initial Debian release. Files: 2a8f07d49f2c66ffd7acfe8158154556 608 misc extra netcdf-perl_1.1-1.dsc dd2acf5b912374b8cb1d73203c3f8221 53781 misc extra netcdf-perl_1.1.orig.tar.gz 5117b3d6e1317540b0bd58afe782 3309 misc extra netcdf-perl_1.1-1.diff.gz 334dc8facadff637e6a92812ab5e3fa5 47680 misc extra netcdf-perl_1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMiSDLvrhbOLeJ39FAQElBAP9Gyn1WW4vZvopYOxAioSp9QvmDyJdbIqC t3X0QnI7f0pqv/7kdw2+gXbDDlCgfr3OmlG1/I3BIs7ytmtvmycVzGS6NuKkDaGC pQxW6U2qhQ3dHfoThdH5wfltcEd9QlSXXTchmA55A/NjvxQymOblr3mbE3Egot48 tZRbnohSEuY= =UTZ6 -END PGP SIGNATURE-
Can someone release the latest i386 kernel packages?
I've noticed that version 2.0.7 of the kernel packages, i.e., kernel-headers, kernel-image, and kernel-source, for the i386 have been sitting in Incoming for about a month. There are no .changes files for these packages, which is probably the reason that they have not been transferred out of the Incoming directory. Last month I saw these packages in Incoming and compiled a new pcmcia-cs package for this kernel version hoping that it would be released along with them. Well, the pcmcia-cs package has been released for kernel version 2.0.7, but the kernel packages in unstable/binary-i386/base are still version 2.0.6. Can someone please transfer these packages to the unstable distribution tree? Thanks. -- Brian
Re: The PCMCIA and kernel packages
Okay. I have created a new version of the pcmcia-cs package and am currently uploading it. Here is a list of the files it creates: pcmcia-cs-1.3.100_2.8.16-1_i386.deb The binary version of the package. It includes the modules compiled for kernel version 1.3.100 and all of the pcmcia-cs utility programs. pcmcia-cs-source_2.8.16-1_i386.deb The deb file containing the package sources. It unpacks into the /usr/src/pcmcia-cs-2.8.16 directory and creates a symbolic link to /usr/src/modules/pcmcia-cs. pcmcia-cs_2.8.16-1.tar.gz The package sources in a compressed tar format. pcmcia-cs_2.8.16-1.diff.gz The diff file describing the debianization done to the original package. Here is a list of the targets of the debian.rules file: Standard Targets: build: Build the package (if not configured, configure according to the running kernel). binary: Make the binary package deb file. This can be used by those who customize their own kernel. clean: Clean the package (undoes the effect of the build target). source: Make a compressed tar file of the source. diff:Make a file of the differences between the debianized package and the original package. Special Targets: configure: Configure the package according to the running kernel. changes: Make a changes file (using dchanges) for this package. source_deb: Make a deb file of the package sources. (pcmcia-cs-source_version_i386.deb) dist:Makes all files required for the Debian distribution. (intended for the package maintainer). Targets to be used by the kernel package: kdist_configure: Configure the package (intended for the kernel maintainer). kdist_image: Make the binary package deb file (intended for the kernel maintainer). kdist: Makes all files required for the Debian distribution (intended for the kernel maintainer). When the kdist targets are used the following three variables should be defined: KVERS: The version number of the kernel source. KSRC:The location of the kernel source. KMAINT: The name of the kernel package maintainer (a pgp key for signing the changes file). The kdist target creates a new version of the package's deb file, but does not create a new source or diff file, since it is assumed that these have not changed. It also executes dchanges to create a changes file. While new source and diff files are not created, if these files are present in the $(KSRC)/.. directory, where the new deb file is placed, they will be included in the changes file. This also is true for the pcmcia-cs-source deb file. The dist target is intended for the package maintainer. It creates both deb files (one for the kernel modules and utilities and the other for the source), the source file, the diff file, and a changes file. If the package has not been previously configured (via a configure or kdist_configure target or by using a make config command), it will be configured using the kernel source configuration in the $(KSRC) directory, just as with the kdist target. The build target makes a new deb file. If the package has not been previously configured (via a configure or kdist_configure target or by using a make config command), it will be configured to work with the current running kernel and will use the kernel source files in the /usr/src/linux directory. This target provides a way to compile the kernel modules without using the kernel-source package. -- Brian Mays
