Re: evan leibovitch and the LPI certification tests
RedCrap already has everyone where they want them; in their back pocket, filling their wallet more and more everyday. Alongside VA Research. So, if this really bothers you, do something about it. Make a company and start marketing the hell out of Debian. That's most of what Redhat is - marketing. That's not a bad thing, necessarily - marketing is what it takes to get your name out in the world. It might be nice if it weren't so important, but it is. Deal with it. As far as Big Companies go, redhat isn't so bad. Be very thankful they didn't go the caldera route, where it seems as if they really don't want to GPL anything they don't have to. Instead, they spend a lot of money funding guys like Alan Cox. And making money for themselves - but that's not a bad thing - that's the goal of most companies. So, if you truly believe in some sort of ideology where making money is bad, that's one thing - don't single out redhat for criticism. If you are bitter about their success, do something about it instead of just whining. Sorry for the long post, and I don't really mean to pick on Phillip, but these rantings are getting kind of lame. They sound, in some sense, a bit juvenile, and not worthy of our time. Personally, I'm happy to know that I'm involved in making a kick ass OS, and as long as no one messes with my ability to do that, I'm fine. Ciao, -- David N. Welton Sors immanis - et inanis - rota tu volubilis, [EMAIL PROTECTED] status malus - vana salus - semper dissolubilis, http://www.efn.org/~davidwobumbrata - et velata - michi quoque niteris; debian.org + prosa.it nunc per ludum - dorsum nudum - fero tui sceleris.
Re: GNU finger
is there already someone building a gnu finger package?? Hi. I posted an intent to package this a while back. I am in consultation with the author at present. Cheers, Matt / Matt Kern Tel: (01223) 366290 | | [EMAIL PROTECTED] http://xanadu.pet.cam.ac.uk/~mwk20/ | O O | | L | If I had better tools, I could more effectively | \__ | demonstrate my total incompetence. \_/
Re: intend to package 'country'
On Tue, May 18, 1999 at 12:46:27PM -0700, Joey Hess wrote: Joel Klecker wrote: What does it use as a datafile? If it doesn't use it already, I suggest /usr/share/zoneinfo/iso3166.tab. My data were extracted from the original ISO document, which includes more information. I know you cann't copyright data, but we probably only need what is already in /usr/share/zoneinfo/iso3166.tab. I think, Joey is right: alias sed(1) and can still get the same results. Good that I posted the intend on the list, my disposition now is not to upload to Incoming. I have to wonder if we really need a package for this, since grep suffices.. -- Ioannis Tambouras [EMAIL PROTECTED], West Palm Beach, Florida Signed pgp-key on key server.
Re: lost packages
On Tue, May 18, 1999 at 07:53:07PM +0200, Michael Meskes wrote: I just checked via dselect to see which packages on my slink/potato machine are not found in the potato archive. I wonder what happened to them. Here's my list (after removing the obvious ones like libgtk1.1.*): manpages-net I noticed this, did a dejanews search, and found that the author considers them alpha releases, and intends them to be rolled into the startard manpages distribution when they're ready, so the Debian packager pulled it. However, they they have not yet found their way the current potato manpages (or manpages-dev), and it would be a shame not to have any reference on some of the newer network calls in the next release. Andrew
Re: evan leibovitch and the LPI certification tests
On Tue, 18 May 1999, David Welton wrote: So, if this really bothers you, do something about it. Make a company and start marketing the hell out of Debian. That's most of what Redhat is - marketing. That's not a bad thing, necessarily - marketing is what it takes to get your name out in the world. It might be nice if it weren't so important, but it is. Deal with it. Now, see, I really would if I could. But I've got a full time job at a startup. That translates to 70 hour weeks sometimes. More often than not. On top of that, I'm already busy advancing Linux on the RS/6000, catching miscellaneous bugs here and there in arch/ppc, and pulling my hair out fixing design flaws in things. As far as Big Companies go, redhat isn't so bad. Be very thankful they didn't go the caldera route, where it seems as if they really don't want to GPL anything they don't have to. Instead, they spend a lot of money funding guys like Alan Cox. And making money for themselves - but that's not a bad thing - that's the goal of most companies. But how do you know they won't go the Caldera route down the line? The fact that they're only in it for the money doesn't really bug me. The fact that they would release such buggy and insecure distributions, however, does. Till they get a real grip on quality control, you won't catch me installing it. And what about their 'partners'? I have yet to see one of their contracts. And I'm just getting this eerie feeling that, well, it's an exclusive contract. If you offer RedHat, you only offer RedHat as far as Linux go, at least on preinstalled systems. VA Research no longer offers SuSE, or Windows either, on any of their systems. Only RedHat 5.2. That bugs me. So, if you truly believe in some sort of ideology where making money is bad, that's one thing - don't single out redhat for criticism. If you are bitter about their success, do something about it instead of just whining. Making money isn't bad. It's how you make it that makes it bad. Sorry for the long post, and I don't really mean to pick on Phillip, but these rantings are getting kind of lame. They sound, in some sense, a bit juvenile, and not worthy of our time. True, but some of them have brought up some pretty valid points. Especially yours. If we don't market Debian, to be blunt, we're going to get fucked. This LPI moron obviously has some serious press contacts. He's got personal reasons. The more damage he can do to Debian, the less credible we seem, and the more power Caldera and RedHat have. And he didn't even mention Slackware, which IMNSHO, is probably the *BEST* distribution if you're going to tinker like hell with it. Bottom line is, unless we can make marketshare magically appear, those people hiding over in debian-pr and all of us here had better get off our asses (those of us who can, that is;) and *SELL SELL SELL!* (Sorry, had to say it.;) Personally, I'm happy to know that I'm involved in making a kick ass OS, and as long as no one messes with my ability to do that, I'm fine. Heh. I won't be happy till Linux is running on every architecture there is. I don't give a damn how obscure, old, or obsolete it is. I want to see Linux on it. Hr.. z80 port, anyone? :) -prj
RE: evan leibovitch and the LPI certification tests
Title: RE: evan leibovitch and the LPI certification tests RedCrap already has everyone where they want them; in their back pocket, filling their wallet more and more everyday. Alongside VA Research. I find it offensive that you attack VA research, who provides many of the resources we enjoy as Debian developers. Regards, -Brent
RE: evan leibovitch and the LPI certification tests
On Tue, 18 May 1999, Brent Fulgham wrote: RedCrap already has everyone where they want them; in their back pocket, filling their wallet more and more everyday. Alongside VA Research. I find it offensive that you attack VA research, who provides many of the resources we enjoy as Debian developers. That's MY opinion. Not necessarily yours. I can't get a system without RedHat preinstalled from VA Research last I checked, they never returned my calls, so as far as I'm concerned, they're about as good a company as Compaq or Microsoft. They're more concerned about PR via donations, and making money, than they are about customer service. -prj
Re: (LONG) Correct non-US solution
On Tue, 18 May 1999, Joey Hess wrote: Well, we've established that no site in the US will carry the crypto stuff. So what if I'm in the US and want to get non-US stuff? Since non-us has disappeared into the distribution, I can't add a line to apt pointing to non-us. So what am I supposed to so? Right in the first draft of the proposal, in the section about modifications to apt, it said: apt will attempt to download the package from the sites in sources.list, and if those fail, will try all the sites in master.list until one is found which hosts the .deb. The master.list file contains all official debian mirrors, in a format that was already outlined. Jonathan
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 10:49:09AM -0400, Phillip R. Jaenke wrote: That's MY opinion. Not necessarily yours. I can't get a system without RedHat preinstalled from VA Research last I checked, they never returned my calls, so as far as I'm concerned, they're about as good a company as Compaq or Microsoft. They're more concerned about PR via donations, and making money, than they are about customer service. From what I've seen of some VA people on the lists, they're quite helpful (eg Chris Dibona - is there a mailing list he ISN'T on?). VA isn't a perfect company, but they're far from evil...they're still growing, from what I've heard they've like quadrupled the amount of employees, and are having some growing pains... As for preinstallation, let me make two points: a) Debian really has a long way to go for someone to do mass installs of it, unattended. b) Even if they DID ship debian preinstalled, how long would you keep it on the machine? Especially since you have remarked that part of your job is security auditing? For me, it would probably be about one boot away from being fdisk'd and reinstalled - one reason to do it would be to set up the partitions the way I want. Also consider this, linux.com is a 100%-debian drive site - from the impressions I've gotten, the VA people are really big on Debian, but for the reasons above aren't doing preinstalls of it. Don't be so quick to judge things. -- Brian Almeida [EMAIL PROTECTED] Debian Linux Developer - http://www.debian.org finger [EMAIL PROTECTED] for GPG/PGP public keys Put simply, Debian is to RedHat what Linux is to Windows.
Re: gpm problems in potato
On Tue, 18 May 1999, Oleg Krivosheev wrote: May 18 16:37:55 reboot /usr/sbin/gpm[109]: Error in protocol May 18 16:37:55 reboot last message repeated 12 times I have this too: May 19 01:57:34 crux /usr/sbin/gpm[652]: No data visually, both gpm and X mouse work just fine Well,under X I have some strange things: sometimes i don't even touch the mouse, and it pastes the last text I've cutted. Another strange thing that in netscape, when I move around, but don't touch the buttons, a new navigator window is opened as if I clicked to a href with middle button. btw I use /dev/gpmdata under X, cause I don't want to change 2/3 buttons on boots when I start windows. on console there's no problem, but under X when I click Ctrl+Midle_button to xterm the menu comes up, but I can't move, 'cause it then closes. Flocsy Gabor Fleischer MAILTO: [EMAIL PROTECTED] URL: http://www.mtesz.hu/~flocsy SMS: [EMAIL PROTECTED] ICQ UIN: 27733935
Hints about future improvements
Hi everyone, some days ago someone had a question about cutting a package into parts. The answer was yes, and one of the reasons: it can decrease the downloads which is espetially good if someone has modem... I was thinking about this, and there's one thing which is not the best it could be, I think: Let's see libc, and the packages that are compiled from the same source, for example locales. I see that libc6 changes so fast, which is good, 'cause it means bugfixes are done fastly. But I think locales don't change, and it's more than 2 MB. The same about the xfonts-(100|75)dpi. Can we figure out a mechanism to solve this? There could be a value in the control file like: Last-changed-version or something similar. apt/dselect could decide from this wether it needs to download this package or not. If the package didn't change since the version already installed the only thing dpkg should do (optionally) that it changes the cache stating that already the latest version is installed. If there wasn't installed a version which is the same as the last, it should download it. The other thing is not as bad, but harder to do something with it. Sometimes when a package is upgraded postinst asks wether I want to upgrade the configfile. This is cool. I see there's a new one, so I go to /etc, 'diff conf-file conf-file.dpkg-new' and see if there's a real change. (Mostly not, maybe there are some new comments/values, which do not really change the program's behaveior) I think a thing like kernel's make oldconfig would be cool to help people at this point. I don't really have an idea how, because dpkg should keep a default of the installed conffiles or have some information in the new ones to see which part is newer than the installed one. Maybe somehow this information could be included in the changelog. Flocsy PS: thinking about adopting the orphaned nfsroot package. Who should I write to?
Re: evan leibovitch and the LPI certification tests
Phillip R. Jaenke [EMAIL PROTECTED] writes: And what about their 'partners'? I have yet to see one of their contracts. And I'm just getting this eerie feeling that, well, it's an exclusive contract. If you offer RedHat, you only offer RedHat as far as Linux go, at least on preinstalled systems. VA Research no longer offers SuSE, or Windows either, on any of their systems. Only RedHat 5.2. That bugs me. That is a completely unfounded fear. You can look at the requirements for their resellers online at: http://www.redhat.com/corp/corp_partners_channel.html This includes the contract. All requirements are bound only to those systems you sell RedHat software on, and you are not required to sell only RedHat software. None of the requirements even mention what you are allowed to sell or not, they just say that you must provide tech support in certain situations, maintain staff that is RH certified, and achieve a minimum level of sales in RH software. There are various reasons why box pusher would want to limit the number of different distributions they support. Internally at my work we limit all of our support to Debian. When you consider that they are dealing with a tremendous number of clients, then limiting the variability of the installation makes it much easier for them to support their clients. If I was a box pusher I might well settle on supporting nothing but Debian. Talking with VA sales indicates that this was probably the primary motivator for reducing the number of distributions they supported, it was having negative effects on the performance of their tech support departments. So, provided we were able to generate more demand for Debian, I could certainly see their position changing. And anyways, there is no call for bad-mouthing organizations that have supported Debian with many resources, especially not when your complaint is mostly FUD and rumor mongering. Complaints about technical reliability are certainly valid, but they should not become the ground for such juvenile name-calling and FUD. In my mind you owe RedHat, VA Research and this list a retraction of your groundless claims and possibly an apology. If we don't market Debian, to be blunt, we're going to get fucked. This LPI moron obviously has some serious press contacts. He's got personal reasons. The more damage he can do to Debian, the less credible we seem, and the more power Caldera and RedHat have. And he didn't even mention Slackware, which IMNSHO, is probably the *BEST* distribution if you're going to tinker like hell with it. Maybe the first thing you should do then is think about what you can constructively say to him and others. You seem to be really good at talking at least, but it's the constructive part that has got you baffled it seems. I would propose, and if noone who is more familiar with Mr. Leibovitch is planning to do so, explaining to him the reasons behind several of Debian's decisions which he is attributing to irrational ideology or some sort. This means explaining that Debian is not against business, and that one of the reasons why we have such strict and well defined guidelines about licensing for packages is so that companies can easily and without fear repackage our work and use it as the base for their own distribution, like Corel is. No other distribution that I know of has made their licensing policy so well defined, and public (which implies stability). We should explain why we chose not to include KDE in our main distribution. That distributing KDE violates a license which is the cornerstone of all Linux distributions (because the kernel is placed under it) the GPL. This is not an ideological position, somehow opposing KDE or QT in favor of GNOME. Debian simply does not want to violate the law in a way which may weaken the binding power of the Free Software communities most important(arguable) license. Perhaps you could better spend your time writing articles about these common misunderstandings about Debian, rather than bad-mouthing, with no real basis, the people who give us the servers and bandwidth we use to create it. I propose that you would win more support for Debian that way, which is what you yourself recommend we do. -- Craig Brozefsky[EMAIL PROTECTED] Less matter, more form! - Bruno Schulz ignazz, I am truly korrupted by yore sinful tzourceware. -jb The Osmonds! You are all Osmonds!! Throwing up on a freeway at dawn!!!
Intent to package: device3dfx
Hi people, device3dfx is a kernel module to allow user-space applications (quake :}) access to 3Dfx cards without needing to be run as root. This package consists *only* of a GPL'd kernel module. As such it can IMHO go into main. It could be argued that you can only use it via the Glide libraries, which aren't free at all, and it should therefore go into contrib. This point may need discussion. Notes: /dev/3dfx -- needs to be created. If this package is accepted, support for it should go into MAKEDEV, as opposed to doing a mknod in the postinst (which lintian complains about). The packaging is based on pcmcia-cs, and I hope it will work with make-kpkg in the same way. I don't use make-kpkg, so I haven't *really* checked, but debian/rules kdist seems to do the right thing. device3dfx, the source package, comes with one binary package, device3dfx-source. This consists of docs and /usr/src/device3dfx.tar.gz, which then extracts to /usr/src/modules/device3dfx/..., which seems right. It can be used to generate device3dfx-modules-* packages. SRH -- Steve Haslam Debian GNU/Linux [EMAIL PROTECTED] gnome-libs, gnome-core, gnome-control-center, gdm, p3nfs.what, me worry? pgpGRtCLH95Nc.pgp Description: PGP signature
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 10:49:09AM -0400, Phillip R. Jaenke wrote: I find it offensive that you attack VA research, who provides many of the resources we enjoy as Debian developers. That's MY opinion. Not necessarily yours. I can't get a system without RedHat preinstalled from VA Research last I checked, they never returned my calls, so as far as I'm concerned, they're about as good a company as Compaq or Microsoft. They're more concerned about PR via donations, and making money, than they are about customer service. VA has been saying that sooner or later they're going to start offering Debian and many people inside VA are working to make it sooner rather than later. I'm not worried about it, there's nothing inherently BAD about Redhat. Granted it's not the same caliber of distribution that Debian is when it comes right down to rock solid stability, but so what? It's still Linux, they still value Free Software... Granted they happen to ALSO value their profit margins, but there's NOTHING WRONG with that. VA does a lot for Debian, a lot for individual Debian developers when they need it, and a lot for the Linux community in general. Been to themes.org recently? VA hosts it---and in fact they hired Trae. www.debian.org is actually va.debian.org, a VA machine using VA's bandwidth. pandora, our new non-us machine.. VA donated it. Even the monitor I'm sitting in front of right this minute... VA donated it to me personally because I could barely read the one I had even in text mode. It's a 19 monitor that I can use (depending on what I'm doing) anywhere from 800x600 to 1153x864 in X, whereas before I could not even RUN X! VA has done a LOT for a LOT of people. They aren't clueless, they aren't trying to rape the community while they promise things they don't devliver. They have never once tried to do something that hurts the community for a quick buck. They've never played games with us. I've said before that I think we have almost nothing to fear from the likes of Micro$oft. We have more to fear from the people who are harming us from within our own ranks. There are companies out there who are hurting us badly, but Redhat and VA Research ain't among them. -- Joseph Carter [EMAIL PROTECTED]Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First! - How many months are we going to be behind them [Redhat] with a glibc release? -- Jim Pick, 8 months before Debian 2.0 is finally released pgpS5KgOstQ5Y.pgp Description: PGP signature
Re: Hints about future improvements
On Wed, May 19, 1999 at 02:51:20AM +0200, Gabor Fleischer wrote: I was thinking about this, and there's one thing which is not the best it could be, I think: Let's see libc, and the packages that are compiled from the same source, for example locales. [...] There could be a value in the control file like: Last-changed-version or something similar. apt/dselect could decide from this wether it needs to download this package or not. [...] Or, we could try to depricate giving the source-package and all of it's associated binary-packages the same version number, even when there are no changes -- more work for the maintainer, without a dought (more places to change the version-number, needing to check in which bin-package the version number should increase, and what _versioned_ interdependincies the packages should have... but it would significantly decrease the bulk of packages that need to be upgraed (glibc-doc and libc6-dev especially). -=- James Mastros -- First they came for the fourth amendment, but I said nothing because I wasn't a drug dealer. Then they came for the sixth amendment, but I kept quiet because I wasn't guilty. Finally they came for the first amendment, and by then it was too late to say anything at all. -=- Nancy Lebowitz cat /dev/urandom|james --insane=yes http://www.rtweb.net/theorb/ ICQ: 1293899 AIM: theorbtwo YPager: theorbtwo
Re: (LONG) Correct non-US solution
On Mon, May 17, 1999 at 12:40:44AM -0700, Jonathan Walther wrote: Package: ssh Export-Restricted: United States Import-Restricted: Russia, France i haven't had time to read or think about your entire proposal yet, but my initial reaction to this is that using country names is wrong, it should instead use the ISO country codes. i.e. us, ru, fr instead of United States, Russia, France. second reaction is that Use-Restricted and Patent-Restriced may be useful fields as well. some countries may not care about import, but do restrict usage, and some may not restrict import or export but patents exist to restrict usage or sale. craig -- craig sanders
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 10:49:09AM -0400, Phillip R. Jaenke wrote: That's MY opinion. Not necessarily yours. I can't get a system without RedHat preinstalled from VA Research last I checked, they never returned my calls, so as far as I'm concerned, they're about as good a company as Compaq or Microsoft. They're more concerned about PR via donations, and making money, than they are about customer service. If you approach them in a similar manner to that you're employing here then it's not altogether surprising that they don't return your calls. The level of abuse you're giving both VA Research and RedHat is completely inappropriate, and you're spreading far too much mindless FUD. Support Debian: get pointless abuse on Debian mailing lists. -- Mark Brown mailto:[EMAIL PROTECTED] (Not selling Debian either) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpgM81wvyCK7.pgp Description: PGP signature
Re: (LONG) Correct non-US solution
Debian is about freedom, specifically freedom of software. Being seen as examplary citizens can only help our cause. We have a sterling reputation for high standards. I agree with you on using the two letter iso country codes. However, I don't see a need for the extra fields Use-Restricted and Patent-Restricted. If a country limits the freedom of the software, then there is no point in importing it. Debian is not set up to cater to a million local regulations, we only want to help get our software on as many mirrors as can legally take it without opening ourselves up to wrath from above. The only reason for bothering with respecting import restrictions is for people who WISH to have boxes compliant with local law, no matter how much that compromises their personal freedom. The case may easily be that violation of the law could limit their freedom even further. How about government funded agencies who don't dare do one thing out of line for fear of losing their government funding? This puts us one step towards being usable and friendly for everyone. If we demonstrably have a solution to that, that puts us far ahead of every other linux distribution in MANY countries out there. Cheers Jonathan On Wed, 19 May 1999, Craig Sanders wrote: my initial reaction to this is that using country names is wrong, it should instead use the ISO country codes. i.e. us, ru, fr instead of United States, Russia, France. second reaction is that Use-Restricted and Patent-Restriced may be useful fields as well. some countries may not care about import, but do restrict usage, and some may not restrict import or export but patents exist to restrict usage or sale.
Re: gpm problems in potato
On Tue, May 18, 1999 at 04:44:55PM -0500, Oleg Krivosheev wrote: May 18 16:37:55 reboot /usr/sbin/gpm[109]: Error in protocol May 18 16:37:55 reboot last message repeated 12 times visually, both gpm and X mouse work just fine any ideas/advices ? This is an artifact of the kernel handing control of the mouse back and forth between gpm and X. This often happens in the middle of a packet of info from the mouse, and therefore looks like corrupt data. If you are not experiencing problems, you need not do anything about this. Otherwise, see /usr/doc/xfree86-common/FAQ in the latest xfree86-common package (3.3.3.1-3). -- G. Branden Robinson |There's nothing an agnostic can't do Debian GNU/Linux |if he doesn't know whether he believes [EMAIL PROTECTED] |in it or not. cartoon.ecn.purdue.edu/~branden/ |-- Graham Chapman pgpQ6nGc7S51v.pgp Description: PGP signature
Re: Hints about future improvements
On Wed, May 19, 1999 at 02:51:20AM +0200, Gabor Fleischer was heard to say: Hi everyone, [snip] There could be a value in the control file like: Last-changed-version or something similar. apt/dselect could decide from this wether it needs to download this package or not. I was browsing the debian-devel archives recently and came across an old thread on distributing binary diffs of packages. Did anything ever come out of that? It looked pretty intriguing but even the program mentioned (xdiff) seems to have vanished from the distribution. Daniel -- Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jeff Raskin
Re: Hints about future improvements
In foo.debian-devel, you wrote: I was browsing the debian-devel archives recently and came across an old thread on distributing binary diffs of packages. Did anything ever come out of that? It looked pretty intriguing but even the program mentioned (xdiff) seems to have vanished from the distribution. I think the ideal solution would be to have a caching proxy based on rsync to communicate with the upstream mirror, and http (or a new apt method) to communicate with apt. -Mitch
Re: evan leibovitch and the LPI certification tests
-Original Message- From: Brian Almeida [EMAIL PROTECTED] To: Phillip R. Jaenke [EMAIL PROTECTED] Cc: Brent Fulgham [EMAIL PROTECTED]; debian-devel@lists.debian.org debian-devel@lists.debian.org Date: Tuesday, May 18, 1999 7:35 PM Subject: Re: evan leibovitch and the LPI certification tests On Tue, May 18, 1999 at 10:49:09AM -0400, Phillip R. Jaenke wrote: That's MY opinion. Not necessarily yours. I can't get a system without RedHat preinstalled from VA Research last I checked, they never returned my calls, so as far as I'm concerned, they're about as good a company as Compaq or Microsoft. They're more concerned about PR via donations, and making money, than they are about customer service. From what I've seen of some VA people on the lists, they're quite helpful (eg Chris Dibona - is there a mailing list he ISN'T on?). VA isn't a perfect company, but they're far from evil...they're still growing, from what I've heard they've like quadrupled the amount of employees, and are having some growing pains... As for preinstallation, let me make two points: a) Debian really has a long way to go for someone to do mass installs of it, unattended. b) Even if they DID ship debian preinstalled, how long would you keep it on the machine? Especially since you have remarked that part of your job is security auditing? For me, it would probably be about one boot away from being fdisk'd and reinstalled - one reason to do it would be to set up the partitions the way I want. Also consider this, linux.com is a 100%-debian drive site - from the impressions I've gotten, the VA people are really big on Debian, but for the reasons above aren't doing preinstalls of it. Don't be so quick to judge things. Agreed, there are people at VA that are Debian bigots just like the rest of us. And Red Hat? Gnome, Video4Linux, Enlightenment, rpm... they put a lot into the Linux community. Mark
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 10:49:09AM -0400, Phillip R. Jaenke wrote: On Tue, 18 May 1999, Brent Fulgham wrote: RedCrap already has everyone where they want them; in their back pocket, filling their wallet more and more everyday. Alongside VA Research. I find it offensive that you attack VA research, who provides many of the resources we enjoy as Debian developers. That's MY opinion. Not necessarily yours. I can't get a system without RedHat preinstalled from VA Research last I checked, they never returned my calls, so as far as I'm concerned, they're about as good a company as Compaq or Microsoft. They're more concerned about PR via donations, and making money, than they are about customer service. Ever tried mass-installing Debian? It's simply impossible -- complete, new debian installations take at least two hours of babysitting. This makes debian a product VA is incapable of marketing. Of course, there are ways around this, like imaging drives and whatnot. But, as someone else mentioned, it costs them money, and they have the right to expend those resources, or not, as they choose. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 07:24:40PM -0700, Aaron Van Couwenberghe wrote: Ever tried mass-installing Debian? It's simply impossible -- complete, new debian installations take at least two hours of babysitting. This makes debian a product VA is incapable of marketing. Of course, there are ways around this, like imaging drives and whatnot. But, as someone else mentioned, it costs them money, and they have the right to expend those resources, or not, as they choose. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson Well, actualy i have semi-mass installed machines...I did 30 or so machines, all i really had to do was put all the packages i wanted to install into a single dir that i nfs mounted(from the base system). i dpkg -i'd those with a program i wrote that parsed the output of dpkg, and gave the answers i specified. Now, i admit this wasn't the best way to mass install, because it did take me 10-20 minutes to get the base system installed, so this is probably too long for a company like VA, but it should be entirely possible to mass install debian, if debian would put some work twords it. Erik Bernhardson [EMAIL PROTECTED] -- [T]he last thing I want to do is spread fear, uncertainty and doubt in [the users'] minds. - Don Jones, Microsoft's Y2K Product Manager pgp4NlrWDetnw.pgp Description: PGP signature
VA Research and linux.com
Wow... Debian gets *lots* of publicity on linux.com. Very cool! -- David N. Welton Sors immanis - et inanis - rota tu volubilis, [EMAIL PROTECTED] status malus - vana salus - semper dissolubilis, http://www.efn.org/~davidwobumbrata - et velata - michi quoque niteris; debian.org + prosa.it nunc per ludum - dorsum nudum - fero tui sceleris.
Re: VA Research and linux.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 May 1999 00:27:16 -0500, David Welton wrote: Wow... Debian gets *lots* of publicity on linux.com. Very cool! Not that it does any good. Wow, this site runs on Debian. *click* Cool, a Linux computer. *click* Whoa, I can only get Red Hat. Huh? - -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your ICQ: 5107343 | main connection to the switchboard of souls. - ---+- -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc iQA/AwUBN0JMXHpf7K2LbpnFEQJA4gCfUHyVPq9jyW4zzEtA92xJ7OQC+5cAn243 JYhePM5fcKodAeEfe3AgknYm =hOnb -END PGP SIGNATURE-
Re: new arch required
Justin Maurer wrote: If you have a compiler packaged, somebody else is working on kernels, i am not sure when the kernel changes will be merged into the linus kernels. whispervger/whisper would you like me to start a list on the ift server? i expect it will be extremley low traffic until at least the kernel can run a shell. No, but on the @lists.debian.org server. And somebody needs to put something into http://www.debian.org/ports/parisc Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists.
Re: lost packages
Michael Meskes wrote: I just checked via dselect to see which packages on my slink/potato machine are not found in the potato archive. I wonder what happened to them. Here's my list (after removing the obvious ones like libgtk1.1.*): conf Oh my goodness! A conf user! I thought those all disappeared with the grea... err waitasec alright this isn't return to zork : I had conf removed from potato because there was no evidence of anyone using it. No bugs had ever been filed against it (I *know* there's bugs in conf), and no dependancies were ever thrust upon it. That combined with the existance of something better (apt-config), as well as the namespace-pollution factor and general dislike of windows .ini-style files led me to conclude that this was not something anyone would be using, nor anything I would want users to be stuck using on behalf of some utility for all time immortal, something a few hundred times more probable if conf were to ever make it into a stable release. See http://www.debian.org/Bugs/db/36/36611.html If you want to take over the package I can send you everything. -- Robert Woodcock - [EMAIL PROTECTED] Now don't you think that's better than some quadrupally redundant, electronic, Microsoft software control system? -- Burt Rutan on the crashworthiness of the Proteus rocket module
Re: Intent to package: device3dfx
One other problem, it needs big warnings, anyone with access to the device can crash the machine no problem... Its vaguely possible that it could also allow more, however I've never seen anyone mention such.. Zephaniah E. Hull.. On Tue, May 18, 1999 at 09:04:18PM +0100, Steve Haslam wrote: Hi people, device3dfx is a kernel module to allow user-space applications (quake :}) access to 3Dfx cards without needing to be run as root. This package consists *only* of a GPL'd kernel module. As such it can IMHO go into main. It could be argued that you can only use it via the Glide libraries, which aren't free at all, and it should therefore go into contrib. This point may need discussion. Notes: /dev/3dfx -- needs to be created. If this package is accepted, support for it should go into MAKEDEV, as opposed to doing a mknod in the postinst (which lintian complains about). The packaging is based on pcmcia-cs, and I hope it will work with make-kpkg in the same way. I don't use make-kpkg, so I haven't *really* checked, but debian/rules kdist seems to do the right thing. device3dfx, the source package, comes with one binary package, device3dfx-source. This consists of docs and /usr/src/device3dfx.tar.gz, which then extracts to /usr/src/modules/device3dfx/..., which seems right. It can be used to generate device3dfx-modules-* packages. SRH -- Steve Haslam Debian GNU/Linux [EMAIL PROTECTED] gnome-libs, gnome-core, gnome-control-center, gdm, p3nfs.what, me worry? -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. pgpC33Z5cvVpJ.pgp Description: PGP signature
Re: VA Research and linux.com
On Wed, May 19, 1999 at 12:27:16AM -0500, David Welton wrote: Wow... Debian gets *lots* of publicity on linux.com. Very cool! Debian seems to be leaping major hurdles at VA.. They've gone from quietly giving va.debian.org to making big donations to the project to making active announcements that they're running Debian on a number of their servers, and that number is going UP. Not to mention the longstanding rumors that soon Debian will be offered on VA's machines.. This is all VERY cool. -- Joseph Carter [EMAIL PROTECTED]Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First! - jgoerzen doogie: you sound highly unstable :-) Knghtbrd jgoerzen - he is. * doogie bops Knghtbrd Knghtbrd see? Resorting to violence =D pgpghlS2yEgfB.pgp Description: PGP signature
Re: Compiling wordinspect for potato
On Mon, May 17, 1999 at 05:02:30PM -0400, Bob Hilliard wrote: I have recently adopted wordinspect and am trying to compile it for potato. The slink version lists the following dependencies: Depends: dict, libc6 (= 2.0.7u), libglib1.1 (= 1.1.3-2), libgtk1.1 (= 1:1.1.\2-2), xlib6g (= 3.3-5) libglib1.1 and libgtk1.1 are not in potato under those names. libglib1.2 seems to be a logical replacement for libglib1.1, but there are many libgtk* libraries. libglib/gtk1.2 is indeed the replacement for all previous versions of libglib/libgtk (but there si still version 1.0 around, not new package should use it, and older packages recompiled against 1.2 if possible) Friendly, Sven LUTHER
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 08:35:50PM -0400, Brian Almeida wrote: a) Debian really has a long way to go for someone to do mass installs of it, unattended. True. Do you think any systems vendor uses the normal installation procedure to install the system software on machines during production? I doubt it. You'd just format the new disk and copy everything across, then put it in the machine. Debian, Windows, whatever, all can be done unattended this way. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: intent to package pa-risc stuff
Justin Maurer wrote: Justin, can you find out if those machines are binary compatible. I've heard that there are two general types flying around (5i and 3i, iirc). I wonder if one new architecture is enough or if we need both - like for mips. which two machines? the ones the puffins are working on? they are working on the a180c (a-class). it is only a 32-bit machine, however. i think it is compatible with all the 64-bit machines, and can confirm this if you'd like and provide me with more info. HP told me that there were two types of machines, or two types of architectures. I'm not familiar with PA RISC so I can't say much. It's possible that the difference was 32 bit and 64 bit. If the code is compatible, that's fine. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists.
Intent to package: apcupsd
apcupsd is a package to monitor and control APC UPS's. Leon -- Leon Breedt | Developer, Obsidian Systems Debian/GNU Linux| Because you want to get there...Today Debian Developer| [EMAIL PROTECTED] Make it idiot proof and someone will make a better idiot.
Re: Intent to package: device3dfx
On Wed, May 19, 1999 at 03:52:11AM -0400, Zephaniah E. Hull wrote: One other problem, it needs big warnings, anyone with access to the device can crash the machine no problem... Its vaguely possible that it could also allow more, however I've never seen anyone mention such.. Someone needs to decide what the permission on the device are too :} I'm currently using [root.audio, 0660]. i.e. the device can be used by anyone in the audio group. It's my understanding this group normally has no members, but people who log in via the console are put in it for a session. Hence I'm using it as a sitting-in-front-of-the-PC privilege. But, yes, this is *still* insecure. So I'll put a (big) warning in the description and the README.Debian. SRH -- Steve Haslam, Validation Engineer, ARM Ltd, Cambridge UK +44-1223-400677 [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] pgphvmcFFZ3Mn.pgp Description: PGP signature
Re: Intent to package: apcupsd
Leon Breedt wrote: apcupsd is a package to monitor and control APC UPS's. May I ask you where I can download its source code? :) I was looking for it some time ago and wasnt able to find any sources of relatively new versions of apcupsd. Anyways, great to have this package in Debian. Regards, -Remco
Re: better /etc/init.d/network
[EMAIL PROTECTED] (Marco d'Itri) writes: On May 18, Erik [EMAIL PROTECTED] wrote: Howabout instead of having eth0, eth1, etc. have like home, work, etc. the files could then have an extra section, called DEVICE or something, that You could make a symlink. Nope, that would start home and eth0 and then you have it setup twice. Normally no harm, but if you have a special up or down script associated with the device that can go wrong. Also you don't want to automatically start home when you are at work. Another paramter, e.g. OPTIONS=default|auto|noauto|user|.. (just like in the fstab) would be needed. That way you could allow any user to ring the modem but not to start/stop eth0. For stuff like home and work another paramter grouping several interface together would be usefull. /etc/network/home could look like this: GROUP=eth0 eth1 eth2 OPTIONS=noauto On boot home would not be started, but when used manually eth0, eth1 and eth2 would be affected. May the Source be with you. Goswin
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 06:10:34PM -0500, David Welton wrote: RedCrap already has everyone where they want them; in their back pocket, filling their wallet more and more everyday. Alongside VA Research. As far as Big Companies go, redhat isn't so bad. Be very thankful they didn't go the caldera route, where it seems as if they really don't want to GPL anything they don't have to. Instead, they spend a lot of money funding guys like Alan Cox. And making money for themselves - but that's not a bad thing - that's the goal of most companies. Hmmm, Alan Cox, Stephen Tweedie, Dave Miller, Federico Mena Qunitero, Raster, ... You'll probably recognize some names ;-) So where's the beef ? Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau)
Re: Hints about future improvements
Gabor Fleischer [EMAIL PROTECTED] writes: Hi everyone, some days ago someone had a question about cutting a package into parts. The answer was yes, and one of the reasons: it can decrease the downloads which is espetially good if someone has modem... I was thinking about this, and there's one thing which is not the best it could be, I think: Let's see libc, and the packages that are compiled from the same source, for example locales. I see that libc6 changes so fast, which is good, 'cause it means bugfixes are done fastly. But I think locales don't change, and it's more than 2 MB. The same about the xfonts-(100|75)dpi. Can we figure out a mechanism to solve this? Its rather difficult to split package into the right amount of chunks. Each chunk has some overhead for download and state information (/var/lib/dpcg gets big). I think the idea of bindiffs would be far more usefull. For bindiffs there are several ways to do this with deb packages: 1. Actually build bindiffs relative to stable. 2. Patch rsync or similar to download changes. (rsync should unpack ar, tar and gz files before syncing) The first approach would mean some load for the server, because for every upload a bindiff must be generated. I think thats not too bad, cause many files will be identicall between versions and take hardly any time (not more than md5sum does). Even diff.debs that contain only changed files would be much smaller and could be generated real fast. The second approach would limit the number of servers one could use and it would mean a lot of load on ALL servers. Every time someone downloads a package it must be unpacked. May the Source be with you. Goswin
Re: (LONG) Correct non-US solution
On Tue, May 18, 1999 at 12:20:35PM +0100, Philip Hands wrote: Perhaps a better goal (although significantly more difficult) would be to design a system where we can have multiple symmetric masters, where you can upload to any of them, and the propagate packages amongst themselves. The Comprehensive TeX Archive Network (CTAN) is set up like this. The network consists of three hosts; uploads can go in any of them, and the files propagate to all of them. If we go with something like this, it would be instructive to study the CTAN setup. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Re: Intent to package: apcupsd
On Wed, 19 May 1999, Remco van de Meent wrote: Leon Breedt wrote: apcupsd is a package to monitor and control APC UPS's. May I ask you where I can download its source code? :) http://www.brisse.dk/site/apcupsd/index.htm#TOP I was looking for it some time ago and wasnt able to find any sources of relatively new versions of apcupsd. It recently was released under the GPL. Martin.
re: ITP: netleds [retract]
Um, It is very similar to tleds, and it is not really worth it, tleds has many more better features... Therfore, I hereby retract my ITP netleds. Michael Beattie ([EMAIL PROTECTED]) PGP Key available, reply with pgpkey as subject. - Bother, said Pooh, as he was assimilated by the Borg. - Debian GNU/Linux Ooohh You are missing out!
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 10:17:11PM -0700, Erik wrote: Well, actualy i have semi-mass installed machines...I did 30 or so machines, all i really had to do was put all the packages i wanted to install into a single dir that i nfs mounted(from the base system). i dpkg -i'd those with a program i wrote that parsed the output of dpkg, and gave the answers i specified. Now, i admit this wasn't the best way to mass install, because it did take me 10-20 minutes to get the base system installed, so this is probably too long for a company like VA, but it should be entirely possible to mass install debian, if debian would put some work twords it. dpkg needs some work before this will become feasible. Many people have proposed ideas, but only one has done any work. Anyone know where doogie's dconfig scripts are? -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: (LONG) Correct non-US solution
Antti-Juhani Kaijanaho writes (Re: (LONG) Correct non-US solution): On Tue, May 18, 1999 at 12:20:35PM +0100, Philip Hands wrote: Perhaps a better goal (although significantly more difficult) would be to design a system where we can have multiple symmetric masters, where you can upload to any of them, and the propagate packages amongst themselves. The Comprehensive TeX Archive Network (CTAN) is set up like this. The network consists of three hosts; uploads can go in any of them, and the files propagate to all of them. If we go with something like this, it would be instructive to study the CTAN setup. If necessary, I could talk to the CTAN folks and find out what they do behind the scenes... I've been doing a little bit of CTAN work (license issue) for a while now and converse fairly regularly with some of the CTAN maintainers. Note that CTAN recently has split their archive into main and non-free trees based upon licenses like we do. :) -- Richard W Kaszeta PhD. Candidate and Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta
Re: (LONG) Correct non-US solution
On Wed, May 19, 1999 at 08:26:21AM -0500, Richard Kaszeta wrote: Note that CTAN recently has split their archive into main and non-free trees based upon licenses like we do. :) Yes, I've noticed it. What criteria do they use? The DFSG? The OSD? A YAFSG (yet another free software guideline)? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Intent to maintainer change: kterm
Package: kterm Kterm package's mainainer Yoshiaki Yanagihara [EMAIL PROTECTED] is very very busy in his main work. He can't maintain some packages. kterm is one of them. We disccussed this point, and I will take over kterm's maintainer. I will upload the package in this week end. - Wed May 19 23:01:40 JST 1999 ISHIKAWA Mutsumi [EMAIL PROTECTED] a trustee of Japan Linux Association [EMAIL PROTECTED] a member of Debian project [EMAIL PROTECTED] a member of Debian-JP project[EMAIL PROTECTED] a member of X-TrueType project (TrueType fonts support for X)
Intent to maintainer change: canna
Package: canna canna package's mainainer Yoshiaki Yanagihara [EMAIL PROTECTED] is very very busy in his main work. He can't maintain some packages. Canna is one of them. We disccussed this point, and I will take over kterm's maintainer. Canna is a japanese input system. I will upload the package in this week end. - Wed May 19 23:14:04 JST 1999 ISHIKAWA Mutsumi [EMAIL PROTECTED] a trustee of Japan Linux Association [EMAIL PROTECTED] a member of Debian project [EMAIL PROTECTED] a member of Debian-JP project[EMAIL PROTECTED] a member of X-TrueType project (TrueType fonts support for X)
Time to rewrite dpkg
Hello, esteemed members of the Debian enthusiast community! Over the last year and a half, as I have been involved in the Debian project, dpkg's shortcomings have been becoming ever more clear to me. Anybody who has worked any significant amount on dpkg knows that its sources are extremely brittle, and that its upstream maintainence is lax. At this time, rpm is regularly having new features and bugfixes integrated with its codebase. Dpkg, howevver, is long overdue for a new release, and even when that happens most of its critical bugs won't be fixed; they simply can't be without upsetting a great portion of its internal workings. This is what's called brittle code. it's been modified too much; It's written in an algorithm-oriented language where the slightest modification can adversely effect all of its being. Changes are difficult to make correctly. So, whether or not I recieve the approval of this community, I'm going to be working on a complete rewrite of dpkg. No, it won't even *resemble* the old dpkg; I guarantee it to become contraversial. I'll let the masses decide whether it warrants trashing the old for the new. Notably, I'm going to be writing it in C++. This will add about 270k to the boot disks' root image, but as the floppy install methods are for the most part phasing out under the shadow of easier methods, I'm not going to lose any sleep over this. libstdc++ can be minimized for static linkage anyway. Why C++? Well, personally, I have been seeing all of these applications pop recently that are for package management, aside from dpkg. Examples include dconfig and apt. Other ideas have been floating about, like source dependencies and binary diffs. I say that most of these applications would benefit greatly from having access to all of dpkg's functionality and variables, so nobody has to reinvent the wheel. I want to make all of these a part of dpkg. Now WAIT! you say. We can't bloat dpkg! Well, we don't have to. It's called modular software, and we have this capability in linux today. dpkg should be able to accept addons at runtime, or to override default behavior by a configuration file explaining where important methods exist. Consider the benefits. First, dpkg comes as a 350k executable, containing nothing but basic logic for commandline arguments and a static link of libstdc++. Apart from that, libdpkg is required for dpkg to function properly; This library defines all behavior for operations on packages and the package/status databases. Now, consider: If I want dpkg to be able to install files via http, I can just plug in the appropriate module and supply the necessary arguments. Now, consider if apt were a module: both dpkg and every frontend written for it would inherit functionality for all available file retrieval methods. This would eliminate much of the kludgery involved with coming up with installation methods for dselect. Consider again something more complicated, like bindiffs. Supplying the appropriate arguments (--unpack-bindiff --retrieve-bindiff) would cause dpkg to load the 'bindiff' module to override every bit of unpacking and retrieval logic. Then, apt and all dpkg front ends would automagically recieve this feature! This is the beauty of polymorphism in OO design. dpkg will remain small, but extensible. The package manager is the distribution, and I think ours has been neglected too long. Anybody with constructive feedback and ideas is encouraged to respond, but negative responses will be ignored. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Intent to maintainer change: im
Package: im IM package's mainainer Yoshiaki Yanagihara [EMAIL PROTECTED] is very very busy in his main work. He can't maintain some packages. IM is one of them. We disccussed this point, and I will take over kterm's maintainer. IM is Internet Message, Mail and News Message Dispatch Agent (used by Mew) I will upload the package in this week end. - Wed May 19 23:18:15 JST 1999 ISHIKAWA Mutsumi [EMAIL PROTECTED] a trustee of Japan Linux Association [EMAIL PROTECTED] a member of Debian project [EMAIL PROTECTED] a member of Debian-JP project[EMAIL PROTECTED] a member of X-TrueType project (TrueType fonts support for X)
Re: Hints about future improvements
On 19 May 1999, Goswin Brederlow wrote: Its rather difficult to split package into the right amount of chunks. Each chunk has some overhead for download and state information (/var/lib/dpcg gets big). I think the idea of bindiffs would be far more usefull. I wouldn't go as far. I'm not thinking about changing the chunks, but if a chunk is not changed, why should I download? I think the package structure is good enough. As I wrote in my first mail, for example binary packages are changing often, but -dev, -doc packages not so often. Also for X, libc there are quite big, stable parts. (fonts, timezones don't change). The things needed to decide if you need a package or not can be put to Packages file, which is downloaded anyway. The program, that makes the diffs for sources, can also have a look at the generated packages, and put the results back to debian/control. Flocsy Gabor Fleischer MAILTO: [EMAIL PROTECTED] URL: http://www.mtesz.hu/~flocsy SMS: [EMAIL PROTECTED] ICQ UIN: 27733935
Re: Intent to maintainer change: canna
On Wed, May 19, 1999 at 11:14:18PM +0900, ISHIKAWA Mutsumi wrote: Package: canna canna package's mainainer Yoshiaki Yanagihara [EMAIL PROTECTED] is very very busy in his main work. He can't maintain some packages. Canna is one of them. We disccussed this point, and I will take over kterm's maintainer. Canna is a japanese input system. I will upload the package in this week end. Usually, you don't need to announce a maintainer change to the lists if it's already been agreed to by both the old and new maintainers, just mark something like '* New maintainer' in the changelog. -- Brian Almeida [EMAIL PROTECTED] - Systems Administrator CICAT Networks - The New Brand of Telecommunications Service Web: http://www.cicat.com/ V: 703-383-1408 email: [EMAIL PROTECTED] F: 703-385-3788 Life's unfair - but root password helps!
Intent to maintainer change: kon2 and konfont
Package: kon2 Package: konfont KON2 and konfont packages' mainainer Yoshiaki Yanagihara [EMAIL PROTECTED] is very very busy in his main work. He can't maintain some packages. KON2 and konfont is one of them. We disccussed this point, and I will take over kterm's maintainer. KON2 is Kanji ON Console (Version2) and konfont is used by KON2 I will upload the package in this week end. - Wed May 19 23:24:18 JST 1999 ISHIKAWA Mutsumi [EMAIL PROTECTED] a trustee of Japan Linux Association [EMAIL PROTECTED] a member of Debian project [EMAIL PROTECTED] a member of Debian JP project[EMAIL PROTECTED] a member of X-TrueType project (TrueType fonts support for X)
Re: pending normal debian bugs for debian-devel@lists.debian.org
[EMAIL PROTECTED] (Marco d'Itri) writes: On May 18, Nag [EMAIL PROTECTED] wrote: #20734 general autoup.sh http://www.debian.org/Bugs/db/20/20734.html #20743 general autoup.sh: wtmp, utmp and btmp http://www.debian.org/Bugs/db/20/20743.html Isn't autoup.sh obsolete? No, it isn't, unless we want to abandon our promise of upgradeability, rather than installing new, for any Debian system. AFAIK, we have lost the capability of upgrading from a.out to elf. Hopefully we won't lose the capability of upgrading from pre-hamm systems. There are still a lot of bo and rex production systems out there. Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9
Source for install program
I'm trying to find the source code to the debian install program (Boot 1 and 2) but can't locate it on the FTP. Can anyone point me to it? ___ Get Free Email and Do More On The Web. Visit http://www.msn.com
Re: Intent to maintainer change: canna
Brian Almeida [EMAIL PROTECTED] wrote Subject: Re: Intent to maintainer change: canna Message-ID: [EMAIL PROTECTED] Usually, you don't need to announce a maintainer change to the lists if it's already been agreed to by both the old and new maintainers, just mark something like '* New maintainer' in the changelog. Thanks for your advice :-) I had read Developpers' Reference. But I can't find description of this case, so I send Maintainer Change announce mail ,just in case. OK, I understand this process for these case. Thank you. - Wed May 19 23:41:38 JST 1999 ISHIKAWA Mutsumi [EMAIL PROTECTED] a trustee of Japan Linux Association [EMAIL PROTECTED] a member of Debian project [EMAIL PROTECTED] a member of Debian JP project[EMAIL PROTECTED] a member of X-TrueType project (TrueType fonts support for X)
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: Why C++? Well, personally, I have been seeing all of these applications pop recently that are for package management, aside from dpkg. Examples include dconfig and apt. Other ideas have been floating about, like source dependencies and binary diffs. I say that most of these applications would benefit greatly from having access to all of dpkg's functionality and variables, so nobody has to reinvent the wheel. I want to make all of these a part of dpkg. That seems... the wrong way around. One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. In particular, there are established ways of linking programs written in any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpzMyPSf54ij.pgp Description: PGP signature
Re: Time to rewrite dpkg
Hello, esteemed members of the Debian enthusiast community! So, whether or not I recieve the approval of this community, I'm going to be working on a complete rewrite of dpkg. No, it won't even *resemble* the old dpkg; I guarantee it to become contraversial. I'll let the masses decide whether it warrants trashing the old for the new. Go for it. Have fun. Document and read. There has been quite some discussion on this subject. My only comment is that apt will likely be on a boot disk near you real soon so libc++ is there too. Make not of dpkg's short comings. Aim for compatibility. Remember the creed of debian always has clean upgrades. And place a cvs somewhere so interested parties can join in the fray.
Re: request to kill nag messages
Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: Time to rewrite dpkg
Hellow Aaron and fellow Debian enthusiasts. :-) Aaron, I would like to get involved with your attempt at rewriting dpkg, especially since it is something I've considered attempting. -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Source for install program
On Wed, May 19, 1999 at 07:40:57AM -0700, Tyger Sunshine-Hill wrote: I'm trying to find the source code to the debian install program (Boot 1 and 2) but can't locate it on the FTP. Can anyone point me to it? See the package boot-floppies. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Re: Time to rewrite dpkg
Hi Anthony, On 20 May, Anthony Towns wrote: One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. In particular, there are established ways of linking programs written in any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. C++ libraries aren't bad once you get to know them. If you are concerned about linking other languages to a C++ library then you can always provide C wrappers around C++ library functions. This isn't an optimal solution. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. Indeed. It is an ambitious endeavor but a worthy one nevertheless, IMHO. Aaron, you've got my support. :) -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: evan leibovitch and the LPI certification tests
Hi, Yeah, you can say I told you so even though... I thought my email got censured... I guess it just got lost, this deb-devel list is busy !! I'm shooting for trinux... it has all the things I like about corporate teamwork like security type integrity and qa controls. And none of the other nasty stuff. Xwin is verboten on Trinux, and that I like feature. My product will hopefully ~use~ trinux, but I am looking at the pokeman crowd. Pretty soon these kids will be using small systems and I would really like to give them a good start and pull some of them into the net devel community I am trying to start for them. --- Phillip R. Jaenke [EMAIL PROTECTED] wrote: On Tue, 18 May 1999, Joseph Carter wrote: I think prj has one such cd from Caldera and I can confirm that I've seen one too. The person who had it wouldn't give it up unfortunately. They're saving it for the same reasons I want it--to show people just what kind of company Caldera really is. I do have one such CD. That's what cost Caldera every shred of my respect. I will GLEEFULLY burn fucking copy after copy for people who want it to see it. It's ANCIENT, but it's basically the same thing they're sending out day after day now as demo CDs. It's legal. 30 day preview license, redistributable. May Caldera rot in hell beside RedCrap and VA Research, who won't give me a system *WITHOUT* RedCrap. -prj === John van Vlaanderen # #CXN, Inc. Contact: # #[EMAIL PROTECTED], www.thinman.com # #1 917 309 7379 (cell, voice mail) # # _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
Re: request to kill nag messages
On Wed, May 19, 1999 at 04:45:11PM +0200, Christian Kurz wrote: And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. Considering the X bug list, I'm sure branden got a quite large mailing from 'Nag' about old bugs - yet from what I understand, he can't possibly go through that list until some modifications are done to the BTS. 'Nag' also goes to developers personally, not only to -devel. -- Brian Almeida [EMAIL PROTECTED] - Systems Administrator CICAT Networks - The New Brand of Telecommunications Service Web: http://www.cicat.com/ V: 703-383-1408 email: [EMAIL PROTECTED] F: 703-385-3788 My software never has bugs. It just develops random features.
Re: locale problem with latest packages
On Tue, May 18, 1999 at 08:47:20PM +0200, J.H.M. Dassen wrote: The requirements have been strenghtened; a proper locale now looks like LC_CTYPE=en_US.iso-8859-1 so you may want to try LC_CTYPE=de_DE.iso-8859-1 . Hmm, after installing -6 all works well again without changing the locale setting. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: VA Research and linux.com
Yep, that's my thought as well. Now, a boxed Debian/book set that gets sold in the software, not just the book section of stores. THAT would not only increase sales of the book, but would make Debian a LOT more popular, and get us more publicity as a distribution. It wouldn't even constitute selling Debian, since they are really just selling the book. Just my 2 cents. Dave Bristel On Tue, 18 May 1999, Steve Lamb wrote: Date: Tue, 18 May 1999 22:30:04 -0700 From: Steve Lamb [EMAIL PROTECTED] To: Debian Development debian-devel@lists.debian.org Subject: Re: VA Research and linux.com Resent-Date: 19 May 1999 05:29:14 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 May 1999 00:27:16 -0500, David Welton wrote: Wow... Debian gets *lots* of publicity on linux.com. Very cool! Not that it does any good. Wow, this site runs on Debian. *click* Cool, a Linux computer. *click* Whoa, I can only get Red Hat. Huh? - -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your ICQ: 5107343 | main connection to the switchboard of souls. - ---+- -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc iQA/AwUBN0JMXHpf7K2LbpnFEQJA4gCfUHyVPq9jyW4zzEtA92xJ7OQC+5cAn243 JYhePM5fcKodAeEfe3AgknYm =hOnb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to rewrite dpkg
* Aaron Van Couwenberghe said: Notably, I'm going to be writing it in C++. This will add about 270k to the boot disks' root image, but as the floppy install methods are for the most part phasing out under the shadow of easier methods, I'm not going to Are you sure about that? If yes, the you probably don't install debian very often. In serveral places, including my own company, which have a few linux workstations and at least one server I like to put the Debian dist CD into the server, mount it in the anon ftp tree and install/upgrade the workstations using FTP - that way I can cut down on costs of the equipment, I can simultaneously install linux on several machines - from ONE source instead of having a dozen copies of the Debian CDs. And, yes, I install from FLOPPIES - now you're telling me the new dpkg won't fit on floppies, right? It won't sell... as I'm sure I'm not the only one installing Linux on workstations this way. Why C++? Well, personally, I have been seeing all of these applications pop recently that are for package management, aside from dpkg. Examples include dconfig and apt. Other ideas have been floating about, like source dependencies and binary diffs. What does it have to do with the actual code? Language chosen is mostly a matter of preference, more often of compatibility and compactness of the produced code. C++ doesn't have the two latter issues... Take a look at what's happening with egcc's support for C++ - it's constantly gaining new features, according to the official standards - to name only one, rtti. Every new language feature in some way changes the way of mangling C++ names, and RTTI will also add entry points for various checking procedures etc. And you will surely have compatibility (binary) problems as the time passes. And code is as good as it's structure and design and not the language used. C programs can be constructed in a very clean, modular and extensible way and they still remain COMPATIBLE and COMPACT. I say that most of these applications would benefit greatly from having access to all of dpkg's functionality and variables, so nobody has to reinvent the wheel. I want to make all of these a part of dpkg. This also dosen't justify the selection of C++ as the language... On the contrary - I'd reccomend NOT to use C++ to create the shared components of dpkg. Remember, most programmers program in C for various reasons, not the very least of them being compatibility. Also, C has the nice feature that libraries written in C can nicely be linked with programs written in almost every other popular language - be it interpreted or compiled - perl, tcl, java, javascript, C++, lisp, scheme - you name it. Most of those interpreted languages have interfaces to use C as the extension language, while they DON'T support (nor they ever will, I presume - again, compatibility) C++... So, if you want't your new dpkg be really extensible, modular and modern - do it in C, but do it it a cleaner way. called modular software, and we have this capability in linux today. dpkg should be able to accept addons at runtime, or to override default behavior by a configuration file explaining where important methods exist. Again, C does it for you, C++ isn't really useful here. Consider the benefits. First, dpkg comes as a 350k executable, containing nothing but basic logic for commandline arguments and a static link of libstdc++. Apart from that, libdpkg is required for dpkg to function properly; This library defines all behavior for operations on packages and the package/status databases. And you call a 350k monster a BENEFIT?? If you have a shared library with ALL the functionality in it, then the DRIVER executable can be as small as 35k - and that's what I call a benefit. Plus, you can do it in C, you can't in C++ - the latter will always be much larger. Now, consider: If I want dpkg to be able to install files via http, I can just plug in the appropriate module and supply the necessary arguments. Now, consider if apt were a module: both dpkg and every frontend written for it would inherit functionality for all available file retrieval methods. This would eliminate much of the kludgery involved with coming up with installation methods for dselect. Once again, this doesn't justify C++... All of this can be done in much cleaner (binary-wise) way in C. Also, you even once didn't mention any feature that's C++ specific and that would justify selection of C++. If you were talking about a hierarchy of classes, encapsulation, polymorphism - then you would justify C++ as THE language for dpkg. I can imagine a hierarchy of classes, each of them designed for a specific task, each of them deriving features from it's parents - and all that in a modular way. Yes, that can be done - but why? It can be done in C equally well... Consider again something more complicated, like bindiffs. Supplying the appropriate arguments (--unpack-bindiff
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 10:03:12AM -0500, Ossama Othman wrote: Hi Anthony, And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. Please don't go into the C++ vs C flamewar here, ... it is as possible to do bad and unmaintainable code in C++ as it is possible to do good and maintainable code in C or another not OO language. what you need is good design, not some magic language to write nice code. Friendly, Sven LUTHER
Re: Time to rewrite dpkg
* Ossama Othman said: One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. Well, a complete rewrite and redesign in C would help... any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. C++ libraries aren't bad once you get to know them. If you are It isn't about C++ libraries being bad, or C++ being bad language, but about compatibility and an issue of C++ still being in a state of flux in a GNU world... And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. That's true, but again, the compatibility and unstability of the C++ implementation on the GNU platform is an obstacle. OTOH, we have Objective C... Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. Good luck, FWIW. I've no doubt you'll need it. Indeed. It is an ambitious endeavor but a worthy one nevertheless, IMHO. Aaron, you've got my support. :) I'm not convinced this is a good way, but I admire the courage - g'luck from me as well :)) regards, marek pgpM0iAcvc1no.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 10:03:12AM -0500, Ossama Othman wrote: On 20 May, Anthony Towns wrote: One alternative that's probably worth considering is improving libdpkg, so that Apt and friends can make use of dpkg that way, and provide their own front ends however they see fit. I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. I was thinking more along the lines of `replacing', than improving. Basically, implementing the fundamental operations dpkg does as a library, then coding a simple, dumb dpkg(1) that links to that library but does little or no more than argument parsing itself. Having C++ wrapper classes around it for Apt and dpkg's convenience maybe, but being just another C-based library at heart. And I don't particularly think it's much of a gain to say You want access to dpkg's internals? Just use C++!. C++ is all well and good, but it's not *that* good. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Oh sure, I've got nothing against OO design/analysis/programming. I don't even have all that much against C++ -- but I don't like the idea of locking any later apps into using C++ if it's /reasonably/ avoidable. In particular, if you find that you're not using too much inheritance/polymorphism for the core functionality of dpkg, you can get most of the benefits of OO programming without contorting C and friends all that much. But at least for the moment, I'm not doing any coding, so it's not my decision. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpVQ5qLDF3Q8.pgp Description: PGP signature
Re: Time to rewrite dpkg
Le Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe écrivait: constructive feedback and ideas is encouraged to respond, but negative responses will be ignored. Whether or not the community approves of this, I will pursue it, and let the chips fall where they may. And what about swim ? It's a dpkg-compatible package manager. I didn't take a look to its sources but maybe you could simply improve swim if it's well written. I don't have an URL right now, but the author is reading this list and he may supply additional informations. Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
mass-installing Debian
I've been thinking a bit about the need for mass-installations. Having done a few of them, it gets to be a tad tedious ... Currently, the preinst and postinst scripts ask the user questions, and make changes according to the responses. Instead of that, we need a general service script that processes a package-specific file containing questions and answer-variables. The results of this get appended to an installation response file that each package can source to retrieve the answers it needs. Hrmm, got that ? For example, exim would use a file : exim-user-info which would contain things like : (excuse the poor examples :) ; exim-domain-name What is the domain name of this system ? /exim-domain-name exim-smarthost What is the smarthost (if any) used ? /exim-smarthost exim-relay-domains Which (if any) domains will you allow relaying for ? /exim-relay-domains ; and so on. The actual variable definitions can be anything, I just used html-style as an example ... The general service script would parse this, looking for a file named package-user-info, and ask the user each of the questions in the file. The responses would go into the installation wide install-response file, like this : ; #!/bin/sh exim-domain=mydomain.org exim-smart-host=smtp.my-isp.com exim-relay-domains=buddydomain.com otherfriend.com ; Now during installation, the exim preinst and postinst scripts would source the install-response file, creating the variables with the responses they need. At this point, it's just as if they've asked the questions and retrieved the user responses. If a particular response variable doesn't exist in the install-response file, the script can still prompt just like normal, though this ruins the effect. Where dselect has the list of packages to be installed and is waiting for the user to select Install, it can run the service script to pre-ask all the config questions. Once that's done, run the normal install and the user can walk away. Even better is combining this with a pre-selected list of packages and a pre-built install-response file. Heh heh, the mechanics of all this is an exercise left to the reader :) -- Dean Carpenter [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
telnet98_98.02.16.orig.tar.gz is wrong
Hi, I don't know which (pseudo-)package I should submit to, so I post it to this list. It seems telnet98_98.02.16.orig.tar.gz in non-us.debian.org:/debian-non-US/dists/potato/main/source differs from that of telnet98_98.02.16-3.dsc. Altough telnet98_98.02.16-3.dsc says dcf4de07acc43f3753f4e8e91f7bd347 283535 telnet98_98.02.16.orig.tar.gz size of telnet98_98.02.16.orig.tar.gz is 283533. misato% ftp non-us.debian.org Connected to non-us.debian.org. (snip) 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp cd /debian-non-US/dists/potato/non-US/main/source 250 CWD command successful. ftp dir telnet98* 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. -rw-rw-r-- 1 1167 1167 6505 Feb 13 09:04 telnet98_98.02.16-3.diff.gz -rw-rw-r-- 1 1167 1167 819 Feb 13 09:04 telnet98_98.02.16-3.dsc -rw-rw-r-- 1 1167 1167 283533 Dec 23 07:15 telnet98_98.02.16.orig.tar.gz So apt-get source telnet98 will fails. Regards, Fumitoshi UKAI
Re: Time to rewrite dpkg
Hi Marek, On 19 May, Marek Habersack wrote: * Ossama Othman said: I don't think that is a complete solution. Improving libdpkg would be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. Well, a complete rewrite and redesign in C would help... Yep, I agree. Although, I still like Aaron's idea. any language against C based libraries. As far as I'm aware doing the same to C++ (or other object-oriented languages) is a pain in the neck. C++ libraries aren't bad once you get to know them. If you are It isn't about C++ libraries being bad, or C++ being bad language, but about compatibility and an issue of C++ still being in a state of flux in a GNU world... Good point. However, now that there is a C++ standard I don't believe that the state of flux you mention is a major issue. EGCS has been fairly stable in terms of existing language feature support. Stuff like RTTI and exception handling aren't major issues since they can easily be disabled. Hrm. I would have to disagree with you. Using object oriented techniques certainly makes things easier to maintain, extend and debug. Using object oriented design patterns (see any good book on OO design patterns), for example, makes code much easier to understand and/or implement. That's true, but again, the compatibility and unstability of the C++ implementation on the GNU platform is an obstacle. OTOH, we have Objective C... I've never tried Objective C. How is it? Is Objective-C link compatible with standard C? Just curious. I'm not convinced this is a good way, but I admire the courage - g'luck from me as well :)) It certainly does seem like it will be difficult. I am sure Aaron has thought this thing through, including the friendly opposition of late. BTW, I just want to thank everyone who has been participating in this discussion for keeping it _friendly_. It can certainly turn into into a C/C++ flame war but I am glad everyone has been calm and rational. Thanks again! :-) -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Listing of Debian hosted cutting-edge software
Over the last few days quite a few cutting-edge development projects have been posted. In particular, Qt2.0 beta at http://master.debian.org/~heiko/qt2/, Configurator Panel at http://linuxlabs.lci.ufrj.br/~lages/cpanel Does debian maintain a list of other cutting-edge software developments which it may or may not host ? If not, I think it would be really cool if one could be made, accessible from the Debian Devel Corner webpage. Thanks ! Geoff Brimhall
re: Time to rewrite dpkg
PLEASEtalk to the guys at Coral! They have been putting out some ideas in this area. PS: I'm not (yet) a developer, I'd like to learn more about the 'nuts and bolts' of the distribution and programming specifics for linux (I've been playing around with gtk++ and VDK for a while now) before I would even consider it. I currently write stuff for an NT platform under C++ using the Rational Rose OO modeling tool, so I agree with your idea of using C++ for this work. GOOD LUCK! === Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
Re: Time to rewrite dpkg
* Ossama Othman said: be good but, as Aaron described, that would just be adding/modifying code to code that is already brittle. Well, a complete rewrite and redesign in C would help... Yep, I agree. Although, I still like Aaron's idea. Yes, it is nice as a venture, IMHO, but at that point of time it's quite, so to say, impractical... C++ libraries aren't bad once you get to know them. If you are It isn't about C++ libraries being bad, or C++ being bad language, but about compatibility and an issue of C++ still being in a state of flux in a GNU world... Good point. However, now that there is a C++ standard I don't believe that the state of flux you mention is a major issue. EGCS has been I was referring not to the standard itself (although it has also it's drawbacks - like the lack of standarized name mangling), but rather to it's implementation on the GNU platform, which is now in its young days - it's constantly changing, the features are being added, standard being implemented in more and more detail. This situation will no doubt incurr many changes both in the source code of the programs (new keywords, syntax changed at places, library classes etc.) but also in the generated binaries interfaces - esp in the shared libraries. fairly stable in terms of existing language feature support. Stuff like RTTI and exception handling aren't major issues since they can easily be disabled. But it DOES change the binary representation of the program, esp. name mangling - which is the major headache with C++ right now. That's true, but again, the compatibility and unstability of the C++ implementation on the GNU platform is an obstacle. OTOH, we have Objective C... I've never tried Objective C. How is it? Is Objective-C link Me neither - I just saw some code, but no documentation. It was just a sudden idea of building a bridge between the two languages we're discussing. compatible with standard C? Just curious. AFAIK, it is quite compatible on the binary level - possibly in 100%. I'm not convinced this is a good way, but I admire the courage - g'luck from me as well :)) It certainly does seem like it will be difficult. I am sure Aaron has thought this thing through, including the friendly opposition of late. Oposition is a minor issue, IMO. What's more important is the compatibility and acceptability of such modification facing the actual needs of the distributuion. Perhaps dpkg, as an application, will gain, but Debian as a distribution will lose - it won't be possible to install it from as wide range of media as now. BTW, I just want to thank everyone who has been participating in this discussion for keeping it _friendly_. It can certainly turn into into a C/C++ flame war but I am glad everyone has been calm and rational. Thanks again! :-) I second that! It's a very rare virtue among the 'Net denizens : marek pgpy7JDgBbLpM.pgp Description: PGP signature
Re: mass-installing Debian
On 19 May 1999, Dean Carpenter wrote: I've been thinking a bit about the need for mass-installations. Having done a few of them, it gets to be a tad tedious ... Currently, the preinst and postinst scripts ask the user questions, and make changes according to the responses. Instead of that, we need a general service script that processes a package-specific file containing questions and answer-variables. The results of this get appended to an installation response file that each package can source to retrieve the answers it needs. Hrmm, got that ? Regarding mass-installations: For the admin: As a start, why couldn't you just 'expect' the first installation, make expect part of base, and use that session to control the entire thing (from selecting the correct package retrieval method on). For the developers: On a related note, couldn't we have an environment variable set at installation time, e.g. NON_INTERACTIVE_DPKG=TRUE, and have the maintainer scripts check this to see if they should ask questions or not? If this variable were set to TRUE, I'd like to see packages which require configuration send mail to root with a message like: To finish configuring bind, please run /usr/sbin/bindconfig If you don't like the idea of sending mail (maybe mail is not yet setup), then have the maintainer scripts write their config commands to a single script, like so: echo /usr/sbin/bindconfig ~root/debian_postinstall_config.sh Then the sysadmin can run this single script to complete the install at her leisure. Perhaps some mechanism like those above can tide the user community over until we have a new tool(set). Comments? [EMAIL PROTECTED] | You won't get wise with the sleep still in http://www.mancill.com | your eyes - no matter what your dream might be. |(Peart)
Re: Time to rewrite dpkg
* Kenneth Scharf said: (I've been playing around with gtk++ and VDK for a while now) before I would even consider it. I currently write stuff for an NT platform under C++ using the Rational Rose OO modeling tool, so I agree with your idea of using C++ for this work. GOOD LUCK! NT (and M$ Winblows in general) platfor has quite a different environment to what you'll meet on Linux and other *nix systems. Windoze is quite homogenous programmer's tool wise and certainly has a better established (read: implemented to the standard) C++ platform. It's different on *nix. marek pgpVGh0h8UZNW.pgp Description: PGP signature
Re: request to kill nag messages
On Wed, 19 May 1999, Christian Kurz wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. This is not a person asking a developer to fix a bug. This is an automated system that spits out messages with NO content of use to the developer, and adds nothing but bulk to the already functional system. This _is_ spam, and nothing more. Please be aware that any message with the word Nag in the subject is always deleted and never read when sent to me, so if you really want to contact me don't use that word ;-) You aren't really suggesting that any well meaning person is correct to set up an automated system for notifying developers about place your important issue here, then you should not complain when some dodo sends you, and the list, critical information about how to get rich quick. He is only trying to be informative... Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: [ITP/mostly packaged] hftpd
On Tue, 18 May, 1999, Michael Stone wrote: On Tue, May 18, 1999 at 02:26:09PM -0700, Chris Waters wrote: Michael Stone [EMAIL PROTECTED] writes: Because too many people don't use debian kernel images. If people don't use the tools, then they don't get the benefits of the tools, which is hardly our fault. This is like saying that we shouldn't have dependencies on libgtk, because some people might compile their own, without using dpkg-source. As long as it works with make-kpkg, and doesn't require one of the *official* kernel images, I'm all for it; there's no valid excuses for not using make-kpkg that I've ever seen. Except that it's a fairly common thing to have to do, and most of the howto's out there don't mention anything about make-kpkg. It's also IMHO not immediately obvious to a new user that he can/should make a kernel package. From /usr/doc/debian/FAQ/debian-faq.txt.gz: - 11.1. What tools does Debian provide to build custom kernels? Users who wish to (or must) build a custom kernel are encouraged to download the package kernel-package_VVV_all.deb (it is stored in section misc at the Debian FTP archives). This package contains the script to build the kernel package, and provides the capability to create a Debian kernel-image package just by running the command make- kpkg kernel_image in the top-level kernel source directory. Help is available by executing the command make-kpkg --help, and through the manual page for make-kpkg(8). Users must separately download the source code for the most recent kernel (or the kernel of their choice) from their favorite Linux archive site. To build a custom kernel, users must have these packages installed: gcc, libc6-dev, bin86, binutils, and make. Executing the command dpkg --install kernel-package_VVV_all.deb sets up the directory /usr/src/linux-VVV/, and sets up the link /usr/src/linux to point to the directory /usr/src/linux-VVV/ containing the kernel sources. Detailed instructions for using the package are given in the file /usr/doc/kernel-package/README. Briefly, one should: o Unpack the kernel sources, and cd to the newly created directory. o Modify the kernel configuration using one of these commands: o make config (for a tty one-line-at-a-time-interface). o make menuconfig (for an ncurses-based menu driven interface). Note that to use this option, the ncurses3.0-dev package must be installed. o make xconfig (for an X11 interface). Using this option requires that relevant X packages be installed. Any of the above steps generates a new .config in the top-level kernel source directory. o Execute the command: make-kpkg -r Custom.N kernel_image, where N is a revision number assigned by the user. The new Debian archive thus formed would have revision Custom.1, e.g., kernel- image-2.0.36-Custom.1.deb for the Linux kernel 2.0.36. o Install the package created. o Run dpkg --install /usr/src/kernel-image_VVV-Custom.N.deb to install the kernel itself. The installation script will: o run the boot loader, LILO (if it is installed), o install the custom kernel in /boot/vmlinuz_VVV-Custom.N, and set up appropriate symbolic links to the most recent kernel version. o prompt the user to make a boot floppy. This boot floppy will contain the raw kernel only. See additional notes for making a ``custom boot floppy''. o To employ a secondary boot loaders (e.g., loadlin), copy this image to other locations (e.g., an MS-DOS partition). - Users will read the documentary. If you were wondering how to complie a kernel in Debian GNU/Linux, the first place you would look would be the Debian FAQ. -- I consume, therefore I am pgp8OXPJLyKt5.pgp Description: PGP signature
Re: request to kill nag messages
On Wed, May 19, 1999 at 12:35:27PM -0400, Dale Scheetz wrote: No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. It does? It sure didn't send that anything like that to me... -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: mass-installing Debian
On Wed, May 19, 1999 at 09:12:29AM -0700, Dean Carpenter wrote: Now during installation, the exim preinst and postinst scripts would source the install-response file, creating the variables with the responses they need. At this point, it's just as if they've asked the questions and retrieved the user responses. If a particular response variable doesn't exist in the install-response file, the script can still prompt just like normal, though this ruins the effect. Hmm... and, if we run dselect, dpkg, apt-get or whatever it is without any system-wide configuration script, it could generate a skeleton file with the user's answers logged. This way we should be able to carefully configure the first machine, cut away the variable configuration fields from the generated configuration script, and feed the rest of the machines with it. Ciao, Illo. -- Ilario Nardinocchi, [EMAIL PROTECTED] - Computer Science Adept since 1982 [EMAIL PROTECTED] Know-nothing-bozo rule: The views expressed above are entirely mine and do not represent the views, policy or understanding of any other person or official body.
Re: Bug#37602: apt: Segfault at the end of apt-get
Joost Kooij wrote: If you're talking about the files in /etc/menu-methods/, those are not programs, they are merly scripts interpreted by install-menu and install-fvwmgenmenu. I think we can agree that the programs/scripts are guilty of causing the segfaults? This is a script #!/bin/cat hello, world! If this causes cat to segfault, the above script is not the thing containing the bug, cat is. If I write a perl script that segfaults, perl is at fault. The authors and maintainer of perl seem to agree with me, since every such perl script I have submitted as a bug has been treated as a bug in perl and fixed. Your statement is unclear. I can agree that whatever binary is interpreting the script is guilty of causing the segfault. If you're instead saying that the _script_ is at fault, I must disagree. -- see shy jo
Re: request to kill nag messages
On Wed, May 19, 1999 at 11:08:02AM -0400, Brian Almeida wrote: Considering the X bug list, I'm sure branden got a quite large mailing from 'Nag' about old bugs - yet from what I understand, he can't possibly go through that list until some modifications are done to the BTS. 'Nag' also goes to developers personally, not only to -devel. I'd like to correct you on this point. I can and do periodically go through the massive list of ancient bugs against X. It's just too much for me to handle. In many cases there is too little information in the bug report for me to reproduce it (or in the case of server bugs, I don't have the hardware to reproduce it). And in many cases they're simply upstream bugs that haven't been fixed yet. I am doing my best with the X bug list, and I am well aware of its size and the age of some of the bugs on it. I do *NOT* need a reminder. There is no way I will ever forget. -- G. Branden Robinson | You can have my PGP passphrase when you Debian GNU/Linux | pry it from my cold, dead brain. [EMAIL PROTECTED] | -- Adam Thornton cartoon.ecn.purdue.edu/~branden/ | pgpzOpZmTsldO.pgp Description: PGP signature
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 05:23:47PM +0200, Sven LUTHER wrote: Please don't go into the C++ vs C flamewar here, ... it is as possible to do bad and unmaintainable code in C++ as it is possible to do good and maintainable code in C or another not OO language. what you need is good design, not some magic language to write nice code. AOLI agree! C, C++, who cares as long as it's build right for what we need today and hopefully can be extended to what we need tomorrow as well../AOL -- Joseph Carter [EMAIL PROTECTED]Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First! - I sat laughing snidely into my notebook until they showed me a PC running Linux And did this PC choke? Did it stutter? Did it, even once, say that this program has performed an illegal operation and must be shut down? No. And this is just on the client. -- LAN Times pgpilpx6Akhzs.pgp Description: PGP signature
Re: request to kill nag messages
[You don't need to send me an extra Cc as I read the lists on which I write. Thanks!] Dale Scheetz [EMAIL PROTECTED] wrote: On Wed, 19 May 1999, Christian Kurz wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. Are you sure? I don't know that this is done by the BTS and have never heard about this? If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. Well what is the problem with this? I don't see any offence in getting a message that says that I (the maintainer) has still open bug over a certain age. I think this is a good reminder for the maintainers as you may forget to fix bugs. Take a look at the ppp-package and how many open bugs there have been. The maintainer hadn't fixed them and so I helped him. (Sorry Phil, but this is a good example and No, I don't want to praise me with this). Or have you taken a look at the list on http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open old bugs we got? How do you think we get this fixed without reminding the developers of their open bugs? This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. This is not a person asking a developer to fix a bug. This is an automated system that spits out messages with NO content of use to the developer, and adds nothing but bulk to the already functional system. Where has the message no content? It tells you which bugs are very old and haven't been fixed, so you can take a look at them and fix them. And the point that this is an automated system doing this is IMHO no cause to treat them like spam. It's has been automated as a normal person can't to this on her own. This _is_ spam, and nothing more. Please be aware that any message with the word Nag in the subject is always deleted and never read when sent to me, so if you really want to contact me don't use that word ;-) Well, that's you problem, but better would be a kill on the From-Line instead of the Subject. You aren't really suggesting that any well meaning person is correct to set up an automated system for notifying developers about place your important issue here, then you should not complain when some dodo sends you, and the list, critical information about how to get rich quick. He is only trying to be informative... Well, I don't like spam as it has nothing to do with my work or my hobby. But these messages are there for informing me, that I have open bugs and that I need to fix them. So it's a reminder for me as developer. Or how should we remind developer of their old bugs? Go by hand through the BTS and sort them out? Are you sure that every developer knows which open bugs he has and how old they are? I'm not and since the messages are not send every day or every week or every month but instead after a certain amount of time, more than 4 months, I don't treat them like spam. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Brian Almeida [EMAIL PROTECTED] wrote: On Wed, May 19, 1999 at 04:45:11PM +0200, Christian Kurz wrote: And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. Considering the X bug list, I'm sure branden got a quite large mailing from 'Nag' about old bugs - yet from what I understand, he can't possibly go through that list until some modifications are done to the BTS. Hm, in the list from NAG are the URLs which lead to the page with the bugreport on it. So what modifications need to be done for making these messages usable? 'Nag' also goes to developers personally, not only to -devel. So where's the problem with getting an reminder about your old open bugs, which you need to fix? Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: Bug#37602: apt: Segfault at the end of apt-get
Hi,
On Wed, 19 May 1999, Joey Hess wrote:
This is a script
#!/bin/cat
hello, world!
There is no official definition of script and program that I know of.
So, although I can understand your sentiments, I certainly do not agree
with your strictness in the matter. But again, this is IMHO not really
the matter.
If this causes cat to segfault, the above script is not the thing containing
the bug, cat is. If I write a perl script that segfaults, perl is at fault.
The authors and maintainer of perl seem to agree with me, since every such
perl script I have submitted as a bug has been treated as a bug in perl and
fixed.
Technically, I wholeheartedly agree with you in the above matter. The
problem _at_hand_ is that a lot of people are seeing a segmentation
fault message. The /primary/ causes are the buggy scripts in
/etc/menu-methods and these should be fixed first.
Apart from that, yes I agree, /usr/sbin/install-{fvwmgen,}menu is buggy to
lose its mind in a segfault and should be properly recoded. But that is
a bugreport to be submitted against menu and not to be discussed on the
topic of a bugreport against apt.
Your statement is unclear. I can agree that whatever binary is interpreting
the script is guilty of causing the segfault. If you're instead saying that
the _script_ is at fault, I must disagree.
Lets conclude that both are guilty, each in a different way :-)
Cheers,
Joost
Re: request to kill nag messages
On Wed, May 19, 1999 at 03:28:16PM -0400, Branden Robinson wrote: I'd like to correct you on this point. I can and do periodically go through the massive list of ancient bugs against X. It's just too much for me to handle. In many cases there is too little information in the bug report for me to reproduce it (or in the case of server bugs, I don't have the hardware to reproduce it). And in many cases they're simply upstream bugs that haven't been fixed yet. Ah, I see. I thought I recalled you saying something on a list that having something added to the BTS would make your job easier...I stand corrected. I am doing my best with the X bug list, and I am well aware of its size and the age of some of the bugs on it. I do *NOT* need a reminder. There is no way I will ever forget. I'd like to think the same of most maintainers out there. Often times if there's an old bug, it's either because it's fixed and forgotten to be closed, unreproducable, or the package/maintainer author feel it not to be a bug - but leave it open so it won't get reported over and over. -- Brian Almeida [EMAIL PROTECTED] - Systems Administrator CICAT Networks - The New Brand of Telecommunications Service Web: http://www.cicat.com/ V: 703-383-1408 email: [EMAIL PROTECTED] F: 703-385-3788 Linux renders ships, NT is rendering ships useless.
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: So, whether or not I recieve the approval of this community, I'm going to be working on a complete rewrite of dpkg. No, it won't even *resemble* the old dpkg; I guarantee it to become contraversial. I'll let the masses decide whether it warrants trashing the old for the new. I don't know what kind of reception you'll get to this (I can see the thread is already large but I'm not going to read the replies till I've said my piece), but... Hey, more power to ya, man. You may very well earn iwj's undying hatred, but what the hell? You're doing the right thing, and saying, I'll show you the code, and then you can do what you want with it. So many people blow onto this list with pie-in-the-sky ideas (configuration registries, etc.) and insist that their proposal is The Right Way To Do It, but nary a scrap of code is seen from them. It is impossible, IMO, that you can't engage in this endeavor without learning a lot, and likewise so will the people who see your code. So, Godspeed. I look forward to hearing about your progress. -- G. Branden Robinson | There is no gravity in space. Debian GNU/Linux | Then how could astronauts walk around [EMAIL PROTECTED] | on the Moon? cartoon.ecn.purdue.edu/~branden/ | Because they were wearing heavy boots. pgpEwAdkS1fsZ.pgp Description: PGP signature
Re: request to kill nag messages
On Wed, May 19, 1999 at 09:28:33PM +0200, Christian Kurz wrote: So where's the problem with getting an reminder about your old open bugs, which you need to fix? I don't NEED a reminder about my bugs. There should be an option to TURN THE BLOODY THING OFF. -- Brian Almeida [EMAIL PROTECTED] - Systems Administrator CICAT Networks - The New Brand of Telecommunications Service Web: http://www.cicat.com/ V: 703-383-1408 email: [EMAIL PROTECTED] F: 703-385-3788 Whip me. Beat me. Make me maintain AIX.
Re: better /etc/init.d/network
On May 19, Craig Brozefsky [EMAIL PROTECTED] wrote: This would make is easier for programs like ipmasq or leafnode or whatever to put hooks to start themselves up or shut themselves down as an itnerface goes up or down. Perhaps we even do soemthing like: /etc/network/eth0.postup.leafnode /etc/network/eth0.postup.fetchmail With this scheme scripts can't be easily disabled. -- ciao, Marco
Re: Two sets of packages for slink and potato. How to version?
On Tue, May 18, 1999 at 03:45:23PM +0200, Stephane Bortzmeyer wrote: The problem is the versioning. How to choose the version numbers in the two sets so that users will automatically get the potato package when they will choose to replace 'stable' by 'unstable' (or when potato will become stable). I've read http://www.debian.org/doc/packaging-manuals/packaging.html/ch-versio ns.html. Should I choose an epoch of 1 for all the potato packages? In general, epochs are Considered Dangerous (for reasons I don't really understand -- but I assume that they are good). I'd suguest subtracting .01 from the debian-version and concatinating '.slink' to the end (somthing like 1.0-0.99.slink); that seems to be standard pratice. -=- James Mastros -- First they came for the fourth amendment, but I said nothing because I wasn't a drug dealer. Then they came for the sixth amendment, but I kept quiet because I wasn't guilty. Finally they came for the first amendment, and by then it was too late to say anything at all. -=- Nancy Lebowitz cat /dev/urandom|james --insane=yes http://www.rtweb.net/theorb/ ICQ: 1293899 AIM: theorbtwo YPager: theorbtwo
Intent to package: GNOME User's Guide, english version
Hi, I will package the GNOME User's Guide, as I want to include it with the GNOME update for slink. I will do the english version for now, maybe later the other languages as well. But someone else is free to pick them up. The license is GPL, source is available at http://www.gnome.org/users-guide/project.shtml . The package will be named gnome-users-guide-en, and it will contain the HTML version of the guide. Ciao, Martin
Re: better /etc/init.d/network
On Wed, May 19, 1999 at 02:36:15PM +0200, Marco d'Itri wrote: This would make is easier for programs like ipmasq or leafnode or whatever to put hooks to start themselves up or shut themselves down as an itnerface goes up or down. Perhaps we even do soemthing like: /etc/network/eth0.postup.leafnode /etc/network/eth0.postup.fetchmail With this scheme scripts can't be easily disabled. chmod -x /etc/network/eth0.postup.leafnode -- Joseph Carter [EMAIL PROTECTED]Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First! - and i actually like debian 2.0 that much i completely revamped the default config of the linux systems our company sells and reinstalled any of the linux systems in the office and here at home.. pgpwEfKr9OIHd.pgp Description: PGP signature
Re: better /etc/init.d/network
[EMAIL PROTECTED] (Marco d'Itri) writes: On May 19, Craig Brozefsky [EMAIL PROTECTED] wrote: This would make is easier for programs like ipmasq or leafnode or whatever to put hooks to start themselves up or shut themselves down as an itnerface goes up or down. Perhaps we even do soemthing like: /etc/network/eth0.postup.leafnode /etc/network/eth0.postup.fetchmail With this scheme scripts can't be easily disabled. mv /etc/network/eth0.postup.leafnode /etc/network/off.eth0.postup.leafnode -- Craig Brozefsky[EMAIL PROTECTED] Less matter, more form! - Bruno Schulz ignazz, I am truly korrupted by yore sinful tzourceware. -jb The Osmonds! You are all Osmonds!! Throwing up on a freeway at dawn!!!
Intent to orphan: libcdaudio
I am going to orphan two packages - libcdaudio and libcdaudio-dev. The grip package, which I maintain, does not use libcdaudio any more. Cdgrab also used to depend on libcdaudio, but it does not any more. There is only one problem with those packages - the new upstream is available, and James Troup nas an NMU ready to upload. Any volunteers to pick it up? Regards, Dima.
Re: Bug#37602: apt: Segfault at the end of apt-get
Joost Kooij wrote: Technically, I wholeheartedly agree with you in the above matter. The problem _at_hand_ is that a lot of people are seeing a segmentation fault message. The /primary/ causes are the buggy scripts in /etc/menu-methods and these should be fixed first. No, the primary cause is a bug in the program used to interpret these scripts. Fix the program and the problems will go away. Modifying the scripts is just a workaround. Debian doesn't go in for quick fixes, we do things right. -- see shy jo
Re: better /etc/init.d/network
On Sun, 16 May 1999, Massimo Dal Zotto wrote: Hi, # /etc/network/eth0 IPADDR=192.168.0.1 NETMASK=255.255.255.0 NETWORK=192.168.0.0 BROADCAST=192.168.0.255 GATEWAY=192.168.0.1 As we're discussing things here... i think it's important that we add the possbility to attach IPv6 addresses to an interface. Since you can have multiple IPv6 addresses on an interface i was thinking of something like this: IPADDR = 192.168.2.1 IP6ADDR = 3ffe:604:5:4::1/80 IP6ADDR = 5ffe:12:2::1/80 Taking the current IPv6 aggregatable addressing scheme in mind it might be better to seperate the prefixes from the addresses, something like: PREFIX6 = 3ffe:604:5:4/80 PREFIX6 = 5ffe:12:2/80 HOST6 = 1 If there's noone objecting to the addition of IPv6 stuff to the interface we could work out a proper way of specifying it on the debian-ipv6 list. Comments? Michel Onstein | CistroN Group| Linux-, Internet- [EMAIL PROTECTED] || Telecom specialists
Re: better /etc/init.d/network
If there's noone objecting to the addition of IPv6 stuff to the interface we could work out a proper way of specifying it on the debian-ipv6 list. IPv6 is supposed to be the future so either we do it now or later. Might as well be now.
