Uploading to pandora (nonus)
Many of you are confused because you are getting messages that your packages are new when they really aren't, or perhaps dinstall is rejecting them because it can't find the orig.tar.gz. Because nonus is now divided into main, non-free, and contrib, you must specify this in the distribution or section, just as you do for an upload to master. So specify the section as `non-us/non-free' or `non-us/contrib'. It's fine to put something after that if you want to, `non-us/non-free/web' for example. It will just be ignored. Also, many people find it very useful to run `dinstall -n foo.changes' to verify that their upload is ok. dinstall is at /org/non-us.debian.org/scripts/dinstall/dinstall on pandora and ~maor/dinstall/dinstall on master. Guy
Re: Uploading to pandora (nonus)
Hi, On Wed, 12 May 1999, Samuel Tardieu wrote: The following doesn't work, I must have missed something obvious. [snip] Try: deb http://pandora.debian.org potato/non-US main contrib non-free It Works For Me(tm). Cheers, Joost
Re: Homapages in list of maintainers
Hi. Thank you for your replies. I got relief to know this long waiting queue issue is rather common to all newcomers. In article [EMAIL PROTECTED] Adam Di Carlo [EMAIL PROTECTED] writes: Yes, well, it takes from 4 weeks to 6 months or longer for *all* people. I agree this should be shorter... Anyhow Debian-JP is *not* getting singled out. Everyone has this issue. I remeber the mail about 6 months waiting recently on this list. It's surely uncomfortable state which should be avoidable as much as we can. IF there's not way the guy can get a phone call, I'm afraid there's no way they can be confirmed and become a developer. Maybe he can get a call on holiday, I suppose. He is only afraid that he can't set time windows to new maitainers team, and he thought that the time of getting the call is unpredictable at all. According to James, all he says is it's unlikely to be between 8AM and 4PM British time on Monday-Friday. No one is asking you to sit by the phone for 3 months. But if you can only be reached at number XX-YYY at the hours of 3-7 GMT on Saturday, then tell the new maintainers that. Give them time windows that work for you. Give them a few different numbers and suggested times. I mean, common sense, people. Thanks for your information. That is what I want to know. Sure, but put people in the queue. It may take up to 3 months or longer if you're hard to reach on the phone -- so just plan on that. 3 months or longer ! (sigh) but if it is required condition, all we can do is just to wait in the queue ... Well, I think it's pretty clear that we need more active people in the New Maintainer Group. I hereby volunteer (I'm in the US, NYC area, and only speak English and smidgeons of Spanish, German, and French). I respect the people in the New Maintainer Group including you for their work. I hope there were the one in Japan, but no one can force the current official maintainer in JP to take charge of it,,, P.S. I think, and hope that the Debian is open project. It is -- don't get paranoid. The New Maintainer Group is just swamped a bit. I think it needs more people -- highly trustable people, of course. I hope the New Maintaier Group can find the highly trustable and active official maintainer as their member in Japan, or somewhere in the far-east area. -- Taketoshi Sano: [EMAIL PROTECTED]
Re: Homapages in list of maintainers
Thank you for your reply. I'm impressed your idea. In article [EMAIL PROTECTED] John Lapeyre [EMAIL PROTECTED] writes: I think it would be great for Debian JP and Debian to find someone in Japan who can do interviews in Japan and report to the new-maintainer people in Debian proper (in Europe or U.S.) That is to say, it would be good to have a new-maintainer person located in Japan. I think so. and more, I hope that the site for dupload established in Japan so that we can select the near site to upload our packages. In current standard /etc/dupload.conf contains chiark (uk), master (us?), erlangen (de), and giano (it). I hope that one of the JP's site is registered as the official upload site. But it may takes some effort in JP project also, and I am only just plain member in JP project, so I have to debate about it in JP project also, not only here,,, This could speed up the process and improve communications. I am glad to hear from you :) Thank you. -- Taketoshi Sano: [EMAIL PROTECTED]
Re: Debian.Org and nameservers
On 10 May 1999, Miquel van Smoorenburg wrote: [debian.org has loads of nameservers] Another thing, according to Internic only 3 servers have been registered as nameservers for debian.org: # host -t ns debian.org a.root-servers.net debian.org NS BUOY.COM debian.org NS WWW2.BUOY.COM debian.org NS VA.debian.org So the nameservers at cistron, fuller, hands, waw and ldsol are of questionable use as well. Not that there is anything wrong with this per se. The extra nameservers could have loads of resolvers using them benefiting from fresh data or they could be feeding internal/firewalled networks. Anyway, the fact is illustrated by this litte hack: http://www.foobar.tm/dns/dnsbajaj.cgi The other way around -- having internic delegating a domain to non- authoritative nameservers -- is a bad thing, making the servers go an extra round to get the data. Using the above tool shows that this is the case for both debian.com and debian.net. Not that I know if those have anything much to do with debian.org? /Bjorn - - - - umop apisdn 'sdoo - - - - Bjorn Isaksson [EMAIL PROTECTED]
Re: Pandora is born
Christian T. Steigies [EMAIL PROTECTED] writes: only one question, were have the uploads landed? I mean, I am very happy that I got confirmation messages, but now I have REJECTED: Rejected: gnupg_0.9.5-1_m68k.deb: Old version 9.5-1' = new version 9.5-1'. but I cant find it on nonus in Incoming/REJECTED? Those files are in /org/non-us.debian.org/incoming/REJECT And what does this mean: (new) pgp-us_2.6.3a-5_m68k.deb optional non-us/utils WARNING: Already present in non-free distribution. I got this kind of message for several pacakges. This is wrong, isnt it? I see that many people are making this error. I'll make an announcement to devel-announce about it. Guy
Re: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 09:08:08PM +0200, Hartmut Koptein wrote: The best list is [EMAIL PROTECTED] The main problem we are facing is our official 2.2.x kernels are huge, and there's no way to put the kernel and the root.bin image on a single floppy. The proposed solution is building a modularized kernel, and loading the needed modules using an initrd image, but AFAICT, there's nobody working on that. What about the ramdisk/root.bin (and then also for the netboot-ramdisk)? They are also very huge now. Floppies with 1.7MB isn't good ... Anybody remember the old slackware adage? The kernel can load its root FS (compressed or not) from a separate floppy. this would bring us up to a measly three floppies for floppy install. Besides, most ppl will be doing CD boots anway -- ..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: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 02:22:10PM -0500, Ossama Othman wrote: It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. I can do this, albeit gradually. Um, to set a time frame, I'd say I could have the majority of the gnome packages built on slink (if everything works smoothly) within a week or so. But first, I don't quite understand the 'proposed-updates' process. someone will need to explain this to me... -- ..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
New non-us and main, and RSA
[follow ups to -policy] I was just taking a bit of a look around the new non-us trying to figure out what our stance was on things like IDEA and RSA and unfortunately can't figure it out. :| (BTW the dns has been swtiched over.. email [EMAIL PROTECTED] if there are issues) It seems from what I have heard that we consider IDEA and RSA to be non-free due to the patents on them in various countries and this is why we have the gpg-rsa and gpg-idea modules in non-free. However we also have libssl, openssl, cipe and ssleay in main which all implement the IDEA (and RSA?) algorithms. So, what is our policy on this? There is a bit of an alterior motive here, it looks like it may be possible to switch completely from PGP for all of Debian signature checking to use GPG and the RSA module in its place, but that may not be legal (or even DSFG?) to do so. This would be very nice as it would be one more large chunk of non-DFSG software that we no longer rely on. Does any know if use of the RSA module (which does not use RSAREF) is even legal in the US? Also, what happens on Sept 20, 2000 when the US RSA patent drops? How many other countries carry this patent? Given that should Debian aim to drop RSA totally or should we aim to stop accepting RSA keys and gradually convert over to a DH/DSS system? Should we just -drop- RSA totally? (AFAIK you do not need IDEA for signatures, only encryption) Thanks, Jason
Re: Release Plans (1999-05-10)
*Aaron Van Couwenberghe wrote: Anybody remember the old slackware adage? The kernel can load its root FS (compressed or not) from a separate floppy. this would bring us up to a measly three floppies for floppy install. Besides, most ppl will be doing CD boots anway I wouldn't mind installing from 2 or three floppies. I think if it has advantages, it's a good idea. There have been times when, for one reason or another, CD and network installs were giving me problems, and I said 'screw it' and made 7 floppies from a neighboring DOS machine and installed from them. For a single machine it is relatively painless. John -- John Lapeyre [EMAIL PROTECTED], [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Upload queue software?
Does anyone know where I can find the software to run a debian upload queue? I thought it was packaged but I can't seem to find it using the obvois searches.. Thanks, Jason
Re: Debian coding style?
Daniel == Daniel Martin [EMAIL PROTECTED] writes: Daniel I will actually point out that although the exact number Daniel 80 is arbitrary, the general number about 80 is not. The reason for 80 chars is the Mr Hollerith decided that 80 columns was all he needed to do the US census of 1889. Everything after this is inertia the choices of the International Business Machines Corp. that said Mr Hollerith founded. It's not by accident that the original IBM CRTs were 80 x 24; exactly two cards in size. Daniel The issue is that that's the number of characters/line Daniel that looks good to the human eye - typesetters know this; Daniel open a book and count. Too much longer than that (say, Daniel 200 columns) and it becomes difficult when tracking your Daniel eye all the way back to the left to find the right row. This may be true; 80 chars is not directly tied to it. -- Stephen --- Long noun chains don't automatically imply security. - Bruce Schneier
/lib/libNoVersion.so.1
I have just had this file appear on my system. It is a broken link and dpkg -S doesn't tell me anything about it. It appeared when I installed about a dozen of the latest potato packages yesterday... Does anyone know what it is about? -- I am in London and would like to meet any Linux users here. I plan to work in London for 6 months and then I might move to some other place where the pay is good.
Re: Homapages in list of maintainers
From: Adam Di Carlo [EMAIL PROTECTED] Subject: Re: Homapages in list of maintainers Date: 11 May 1999 03:18:28 -0400 I would hope that we could accept official Japanese identification. I'd have to leave it up to James to say for sure. I believe that what kind of idetification is acceptable is essential issue. I hope that the condition of identification is stated much more explicitly and practically so that it causes no confusion. Yes -- it really sounds like we need a native Japanese new maintainer processor, or at least someone fluent. I hope this *does* happen but it may take a while to happen. Remember that approving new maintainer is a very _sensitive_ area -- I know James is a little (justifiably) paranoid about delegating this to others. Thank you for your kind comments. 1999.5.12 -- ** Atsuhito Kohda Dep. Math., Tokushima Univ. [EMAIL PROTECTED]
Re: dependency of magicfilter
From: James A. Treacy [EMAIL PROTECTED] Subject: Re: dependency of magicfilter Date: Mon, 10 May 1999 12:17:47 -0400 Note that the same problem occurs when using magicfilter with gs-aladdin. You are right. So I searched the lists of BTS and found that the same problem is already reported. I should check the lists of BTS first. Thank you for your kind comments. 1999.5.12 -- ** Atsuhito Kohda Dep. Math., Tokushima Univ. [EMAIL PROTECTED]
Re: Intent to package t-gnus
In article [EMAIL PROTECTED], ADC == Adam Di Carlo [EMAIL PROTECTED] wrote... ADC Are these two JP specific? I noticed from your uploads that the ADC install fails if LANG is unset or set as C. This kinda warned me ADC that maybe it wouldn't work for english? No. Not JP specific. Only at Byte-compile is needed LANG=ja_JP. When other, work on LANG=any, maybe. I think that the ploblem is xemacs20-mule's problem(Bug). (Ploblem will happend with xemacs20-mule.) I'm checking and asking SEMI authors that. Regards. -- Takuro KITAME [EMAIL PROTECTED] [EMAIL PROTECTED] / [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Upload queue software?
Jason Gunthorpe wrote: Does anyone know where I can find the software to run a debian upload queue? I thought it was packaged but I can't seem to find it using the obvois searches.. There is a tar.gz file in project/misc. -Remco
jdk117v3 package?
a new version of jdk117 from blackdown (v3) has been released. apparently, the problems with glibc2.1 have been resolved, though i haven't checked this out myself. is anybody working on packaging it? can i help? -vinny -- Vincent Murphy | CompSci Undergrad, UCC | [EMAIL PROTECTED] | (086) 8397405 With a PC, I always felt limited by the software available. On Unix, I am limited only by my knowledge. --P J Schoenster
Re: Release Plans (1999-05-10)
AVC == Aaron Van Couwenberghe [EMAIL PROTECTED] writes: [ GNOME rebuild for slink ] AVC I can do this, albeit gradually. Um, to set a time frame, I'd say AVC I could have the majority of the gnome packages built on slink AVC (if everything works smoothly) within a week or so. Not to double effords: I installed slink in an vmware environment on my main box yesterday, and started rebuilding. It is a PII 300 with 128 MB Ram, so compiling is much faster than on my dedicated P90 48 MB slink box. So far, I have Contact me per mail, so we can coordinate on this (and further discussion should be on debian-gtk-gnome). The vmware environment is great. Finally a way to compile for slink on a potato box. And it is great for testing. You can test installations (and take screenshots), test upgrade paths and discard the changes made during the session, so you can try again from the same point etc. It is bloody non-free, so most likely I get kicked in the ass for this :-), but how about asking them, if they could donate some of the final products for developement of debian? I know, I could make some space on the disk for a seperate partition, but vmware still has some advantages (no repartitioning, growing diskusage as it is needed, ability to discard changes, runs as a window in a controlled environment). AVC But first, I don't quite understand the 'proposed-updates' AVC process. someone will need to explain this to me... The upload should go into the slink staging area first, so it can be tested. www.debian.org/~jim has a readme how to do this. Ciao, Martin
Re: Release Plans (1999-05-10)
MB == Martin Bialasinski [EMAIL PROTECTED] writes: Aargh, send too early... MB So far, I have imlib, orbit, gtop, gtk-engines and I am building bone-libs right now. In the FAQ on the gnome site, there is info anout the sequence you have to use. Ciao, Martin
Re: Uploading to pandora (nonus)
In article [EMAIL PROTECTED], Guy Maor [EMAIL PROTECTED] wrote: Many of you are confused because you are getting messages that your packages are new when they really aren't, or perhaps dinstall is rejecting them because it can't find the orig.tar.gz. Because nonus is now divided into main, non-free, and contrib, you must specify this in the distribution or section, just as you do for an upload to master. So specify the section as `non-us/non-free' or `non-us/contrib'. It's fine to put something after that if you want to, `non-us/non-free/web' for example. It will just be ignored. How do I distinguish between stable and unstable in this scenario ? How do I define that my package should go into: - unstable - non-US - main or - unstable - non-US - non-free There is something I have never understood and can't find in the docs either. Since I don't have any non-free or non-US packages (yet) I never had to worry about this. Mike. -- Indifference will certainly be the downfall of mankind, but who cares?
Re: Uploading to pandora (nonus)
On Wed, May 12, 1999 at 12:40:31 +0200, Samuel Tardieu wrote: What should be put in sources.list files? deb ftp://non-us.debian.org/debian-non-US unstable non-US/main non-US/contrib non-US/non-free HTH, Ray -- Obsig: developing a new sig
Re: Release Plans (1999-05-10)
Previously Martin Bialasinski wrote: The vmware environment is great. Finally a way to compile for slink on a potato box. And it is great for testing. You can test installations (and take screenshots), test upgrade paths and discard the changes made during the session, so you can try again from the same point etc. But vmware is non-free while there is a perfect method to do the same without vmware: simply create a chroot slink environment and work in there. The simplest way to do that is to extract the base system somewhere and as root cd into it and to chroot bin/sh. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgp7ItpC9IoGN.pgp Description: PGP signature
Re: Uploaded mysql 3.22.22-1 (source i386) to erlangen
On Wed, 12 May 1999, Christian Hammers wrote: Files: cf79475df098c2e9a87087404eb98a86 664 misc optional mysql_3.22.22-1.dsc 1a0eedbe7cda20845ec2e767b96ade5c 3762716 misc optional mysql_3.22.22.orig.tar.gz 9fb7fcddfad966f66d9d5b6f2e0dea00 15068 misc optional mysql_3.22.22-1.diff.gz 0205ea7a04fc53a718a02d767f5891cc 581914 misc optional mysql-server_3.22.22-1_i386.deb 94a8edeac6090d689864eff3cab844ad 162414 misc optional mysql-client_3.22.22-1_i386.deb 4203936b27eb615017501f90465ecdd4 1058968 misc optional mysql-doc_3.22.22-1_i386.deb 0fd69d5fd278225bf33dafcbf08b078c 180248 devel optional mysql-dev_3.22.22-1_i386.deb Shouldn't these be in non-free ? -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: Uploading to pandora (nonus)
Le Wed, May 12, 1999 at 12:40:31PM +0200, Samuel Tardieu écrivait: The following doesn't work, I must have missed something obvious. Yes. :) deb http://nonus.debian.org/debian-non-US unstable non-us/main non-us/contrib non-us/non-free It's non-US/main non-US/contrib non-US/non-free ! Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: Upload queue software?
Hi Jason! Does anyone know where I can find the software to run a debian upload queue? I thought it was packaged but I can't seem to find it using the obvois searches.. It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian package because it runs on other Unixes, too (mine runs under Solaris). Roman
Re: Uploading to pandora (nonus)
So specify the section as `non-us/non-free' or `non-us/contrib'. It's fine to put something after that if you want to, `non-us/non-free/web' for example. It will just be ignored. How do I distinguish between stable and unstable in this scenario ? That goes in the changelog entry, and will be automatically handled by the dpkg-* scripts. How do I define that my package should go into: - unstable - non-US - main debian/changelog first line: ssh (1.2-34) unstable; urgency=low debian/control file contains: Section: non-us/net or - unstable - non-US - non-free debian/control file contains: Section: non-us/non-free HTH, Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Uploading to pandora (nonus)
Miquel van Smoorenburg wrote: So specify the section as `non-us/non-free' or `non-us/contrib'. It's fine to put something after that if you want to, `non-us/non-free/web' for example. It will just be ignored. How do I distinguish between stable and unstable in this scenario ? By the debian/changelog file? I think Guy was talking about debian/control.. bye, -Remco
Re: Uploading to pandora (nonus)
On Wed, May 12, 1999 at 12:38:36PM +0200, Miquel van Smoorenburg wrote: How do I distinguish between stable and unstable in this scenario ? How do I define that my package should go into: - unstable - non-US - main or - unstable - non-US - non-free There is something I have never understood and can't find in the docs either. Since I don't have any non-free or non-US packages (yet) I never had to worry about this. Distributions are named stable, unstable and frozen. Sections are named main, contrib, non-US and non-free. Subsections are admin, base etc. However, in the non-US case, the subsections aren't admin, base et al, but main, contrib and non-free. There aren't any subsubsections, like admin, base etc., but that is not important since there aren't that many non-US applications. So, for example, GnuPG package would have `Section: non-US/main` in its debian/control file, and ssh would have `Section: non-US/non-free`. -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Uploading to pandora (nonus)
On Wed, 12 May 1999, Julian Gilbey wrote: debian/control file contains: Section: non-us/net or - unstable - non-US - non-free debian/control file contains: Section: non-us/non-free Who decides weather a non-US package goes in non-US/main, non-US/contrib or non-US/non-free? Are there any guidelines available? Practical question from a porter: imagine some of my recent uploads have rejected, because they do not follow yet the new sceme. Allthough when the source package was uploaded, there was no new scheme yet. Now when I build that package I have to edit debian/control as a porter otherwise the port will not be included until the maintainer edits debian/control? And when I edit it, I'll have to find out myself in which section the package will go, ie by locating the source/i386-bin package on the non-US server? Maybe all non-US packages should be repacked... Ciao, Christian.
Re: Uploading to pandora (nonus)
On Wed, May 12, 1999 at 14:08:13 +0200, Christian T. Steigies wrote: Who decides weather a non-US package goes in non-US/main, non-US/contrib or non-US/non-free? Are there any guidelines available? This is the subject of current threads in debian-policy; please follow those. Ray -- Obsig: developing a new sig
Re: Homapages in list of maintainers
On Wed, May 12, 1999 at 08:09:01AM +0900, Taketoshi Sano wrote: I hope that the site for dupload established in Japan so that we can select the near site to upload our packages. In current standard /etc/dupload.conf contains chiark (uk), master (us?), erlangen (de), and giano (it). I hope that one of the JP's site is registered as the official upload site. But it may takes some effort in JP project also, and I am only just plain member in JP project, so I have to debate about it in JP project also, not only here,,, You just have to have an Incoming directory on one of your servers (maybe ftp.debian.or.jp?), and the queue daemon (that is used on chiark, erlangen and giano) installed. Coordinate that with your FTP admins, and with one of the developers from both Debian and Debian JP. Coincidentally, jgg already asked for the location of the queue daemon on this list recently - it's in project/misc/debianqueued-0.8.tar.gz Remember to inform [EMAIL PROTECTED] when you set it up, so he can update his /etc/dupload.conf file. -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 01:16:07PM -0700, Matt Porter wrote: On Mon, 10 May 1999, Hartmut Koptein wrote: There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... Friendly, Sven LUTHER
Re: Uploading to pandora (nonus)
In article [EMAIL PROTECTED], Josip Rodin [EMAIL PROTECTED] wrote: So, for example, GnuPG package would have `Section: non-US/main` in its debian/control file, and ssh would have `Section: non-US/non-free`. Ah, OK. Thanks. libapache-mod-ssl will have Section: non-US/main then. Mike. -- Indifference will certainly be the downfall of mankind, but who cares?
Re: Uploading to pandora (nonus)
On Wed, May 12, 1999 at 02:08:13PM +0200, Christian T. Steigies wrote: Who decides weather a non-US package goes in non-US/main, non-US/contrib or non-US/non-free? Are there any guidelines available? Yes, actually, the Debian Free Software Guidelines :) Software that is threatened by US crypto laws goes to non-US (and some other problems), but that doesn't mean that the software's licence doesn't matter. I'd say, look at it this way: first remove the goverment imposed restrictions from the package, and then look at the licence of the program. If it fails the DFSG, it goes to non-US/non-free, otherwise, it goes into non-US/main (or if it depends on software in non-US/non-free or just non-free, it goes into contrib). Now when I build that package I have to edit debian/control as a porter otherwise the port will not be included until the maintainer edits debian/control? And when I edit it, I'll have to find out myself in which section the package will go, ie by locating the source/i386-bin package on the non-US server? Maybe all non-US packages should be repacked... I suggest filing bugs against the packages that don't follow the correct procedure. The change is really trivial (it involves reading the licence - yes, that can be hard, but we all had to do it for other packages). -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Uploading to pandora (nonus)
Practical question from a porter: imagine some of my recent uploads have rejected, because they do not follow yet the new sceme. Allthough when the source package was uploaded, there was no new scheme yet. Now when I build that package I have to edit debian/control as a porter otherwise the port will not be included until the maintainer edits debian/control? I'd edit the resulting .changes file instead (before signing). That's easier. And when I edit it, I'll have to find out myself in which section the package will go, ie by locating the source/i386-bin package on the non-US server? Yes :-( Roman
Re: Release Plans (1999-05-10)
There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. Thnx, Hartmut
Intent to package pipsecd
Source: pipsecd Maintainer: Samuel Tardieu [EMAIL PROTECTED] Section: net Priority: optional Standards-Version: 2.5.1.0 Package: pipsecd Architecture: any Description: IPsec tunnel implementation This package allows secure tunnels (to build virtual private networks for example) between two hosts.
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 03:09:02PM +0200, Hartmut Koptein wrote: There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. Friendly, Sven LUTHER
Re: Debian coding style?
On Sun, May 09, 1999 at 08:01:44PM +0300, Antti-Juhani Kaijanaho wrote: On Sun, May 09, 1999 at 01:37:19PM +1000, Anthony Towns wrote: Or Norman Ramsey's NoWeb, which also has a large following and is language independent. ... or write in Haskell, which has standard support for literate programming ;-) # apt-get install hugs98 -- the Haskell User's Gofer System But it is non-free, as well as any other modern language around there, no free haskell implementation, no free ML family language, ... Friendly, Sven LUTHER
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 12:20:15PM +0200, Martin Bialasinski wrote: MB == Martin Bialasinski [EMAIL PROTECTED] writes: Aargh, send too early... MB So far, I have imlib, orbit, gtop, gtk-engines and I am building bone-libs right now. In the FAQ on the gnome site, there is info anout the sequence you have to use. Ok, um, then I will write some scripts today for a slink-gnome-stage-area. ;) Stay tuned. Ciao, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ..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: Release Plans (1999-05-10)
WA == Wichert Akkerman [EMAIL PROTECTED] writes: WA But vmware is non-free while there is a perfect method to do the WA same without vmware: Looks like the thing I was looking for. For compilation, this should work, I will try it. WA simply create a chroot slink environment and work in there. WA The simplest way to do that is to extract the base system WA somewhere and as root cd into it and to chroot bin/sh. I never done this, so some additional questions: Do I have access to the net within that environment? I just have some pre-release slink CDs, so I have to upgrade to the current point release by ftp (by an ISDN line - it is accessed like a NIC). Do I have access to $DISPLAY somehow and can I use startx, so I can test X packages directly? Ciao, Martin
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 01:43:57PM +0200, Martin Bialasinski wrote: WA == Wichert Akkerman [EMAIL PROTECTED] writes: WA But vmware is non-free while there is a perfect method to do the WA same without vmware: Looks like the thing I was looking for. For compilation, this should work, I will try it. WA simply create a chroot slink environment and work in there. WA The simplest way to do that is to extract the base system WA somewhere and as root cd into it and to chroot bin/sh. not entirely sure about this, but i think a chrooted environment is exactly like you booted from the environment you chrooted to. Friendly, Sven LUTHER
Re: Uploaded ssh 1.2.26-4 (source i386) to non-US
On 12 May 1999 [EMAIL PROTECTED] wrote: ssh (1.2.26-4) unstable; urgency=low . * make sure that ssh1 gets user suid bit set (closes: #37127) Files: 264c7c1726f8d333a7de8c356bd7a73e 619 non-us/net optional ssh_1.2.26-4.dsc 8346f02e1de9f0771a56612e044b2b91 46926 non-us/net optional ssh_1.2.26-4.diff.gz d24a8fe61a54ecace08cf6349bfd5e93 430966 non-us/net optional ssh_1.2.26-4_i386.deb 33d2642924205944373e7335933874bd 40768 non-us/net optional ssh-askpass_1.2.26-4_i386.deb I guess this will be rejected... where should it go (no, I will not subscribe to debian-policy now...) non-US/main because we all need it? non-US/contrib because it needs rsaref to compile? non-US/non-free because rsaref is also in non-US? Ciao, Christian.
Re: Debian coding style?
On Wed, May 12, 1999 at 03:16:25PM +0200, Sven LUTHER wrote: # apt-get install hugs98 -- the Haskell User's Gofer System But it is non-free Oh. Perhaps then hugs98 should be moved out of main, yes? Hugs98 is under the Artistic license. -- Antti-Juhani Kaijanaho A7 [EMAIL PROTECTED] ** URL:http://www.iki.fi/gaia/ ** The FAQ is your friend. Trust the FAQ.
Re: Release Plans (1999-05-10)
Previously Martin Bialasinski wrote: Do I have access to the net within that environment? I just have some pre-release slink CDs, so I have to upgrade to the current point release by ftp (by an ISDN line - it is accessed like a NIC). Sure. You are just using the same system, only the root of the filesystem is changed for processes running in the chroot-environment. Do I have access to $DISPLAY somehow and can I use startx, so I can test X packages directly? If you use localhost:0.0 you can use the same display (note that :0.0 doesn't work since the X-socket is in a location the chroot-environment cannot access). If you want to do startx you have to use a different display since X is already running. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpfqOKeRbVNJ.pgp Description: PGP signature
Re: /lib/libNoVersion.so.1
In reference to a message from Russell Coker, dated May 12: I have just had this file appear on my system. It is a broken link and dpkg -S doesn't tell me anything about it. It appeared when I installed about a dozen of the latest potato packages yesterday... Does anyone know what it is about? Most likely you installed a package from redhat that is converted with alien. afaik, that's a redhat library, not a part of debian. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/
Re: Debian coding style?
On Wed, May 12, 1999 at 04:48:29PM +0300, Antti-Juhani Kaijanaho wrote: On Wed, May 12, 1999 at 03:16:25PM +0200, Sven LUTHER wrote: # apt-get install hugs98 -- the Haskell User's Gofer System But it is non-free Oh. Perhaps then hugs98 should be moved out of main, yes? Hugs98 is under the Artistic license. Sorry, you are right, it is the hugs package who is non-free, didn't know there was a free version around. Nice to know, ... Friendly, Sven LUTHER
Re: /lib/libNoVersion.so.1
On Wed, 12 May 1999, Randolph Chung wrote: In reference to a message from Russell Coker, dated May 12: I have just had this file appear on my system. It is a broken link and dpkg -S doesn't tell me anything about it. It appeared when I installed about a dozen of the latest potato packages yesterday... Does anyone know what it is about? Most likely you installed a package from redhat that is converted with alien. afaik, that's a redhat library, not a part of debian. No I haven't installed any RPMs recently. In fact AFAIR I have never installed an RPM on this machine. Thanks for the suggestion though. Russell Coker
Re: /lib/libNoVersion.so.1
In reference to a message from Russell Coker, dated May 12: I have just had this file appear on my system. It is a broken link and dpkg -S doesn't tell me anything about it. It appeared when I installed about a dozen of the latest potato packages yesterday... Does anyone know what it is about? sorry, i was wrong... :) it was part of libc6, but doesn't seem to be in newer versions of the deb package. my apologies, randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/
Re: /lib/libNoVersion.so.1
On Wed, May 12, 1999 at 10:03:22AM -0400, Randolph Chung wrote: I have just had this file appear on my system. It is a broken link and dpkg -S doesn't tell me anything about it. It appeared when I installed about a dozen of the latest potato packages yesterday... Does anyone know what it is about? Most likely you installed a package from redhat that is converted with alien. afaik, that's a redhat library, not a part of debian. Hmm. The only Red Hat package that I've messed with is the Voodoo Banshee version of the the XF86_SVGA server, but for it I only used alien to make a tgz file from which I extracted a few files by hand. Nevertheless, I have seen the same link as the original poster. I, too, am curious about the origin of this link, but I am inclined to think that your hypothesis is not most likely the answer. -- Thomas E. Vaughan [EMAIL PROTECTED] Dept. of Physics Astronomy home: (405) 366-8721 University of Oklahoma, Norman office: (405) 325-3961x36403
Re: Uploaded ssh 1.2.26-4 (source i386) to non-US
On Wed, May 12, 1999 at 03:44:15PM +0200, Christian T. Steigies wrote: 264c7c1726f8d333a7de8c356bd7a73e 619 non-us/net optional ssh_1.2.26-4.dsc 8346f02e1de9f0771a56612e044b2b91 46926 non-us/net optional ssh_1.2.26-4.diff.gz d24a8fe61a54ecace08cf6349bfd5e93 430966 non-us/net optional ssh_1.2.26-4_i386.deb 33d2642924205944373e7335933874bd 40768 non-us/net optional ssh-askpass_1.2.26-4_i386.deb I guess this will be rejected... I doubt it, since the old ssh package is already in place, so this'll probably get overriden. where should it go (no, I will not subscribe to debian-policy now...): non-US/main because we all need it? Definitely not that. non-US/non-free because rsaref is also in non-US? In there, because the licence is clearly not DFSG free. See /usr/doc/ssh/copyright, the very title says: SSH (Secure Shell) NON-COMMERCIAL LICENSE (Version 1, May 27th, 1996) ~~ -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Uploaded ssh 1.2.26-4 (source i386) to non-US
On 12 May 1999 [EMAIL PROTECTED] wrote: ssh (1.2.26-4) unstable; urgency=low . * make sure that ssh1 gets user suid bit set (closes: #37127) Files: 264c7c1726f8d333a7de8c356bd7a73e 619 non-us/net optional ssh_1.2.26-4.dsc 8346f02e1de9f0771a56612e044b2b91 46926 non-us/net optional ssh_1.2.26-4.diff.gz d24a8fe61a54ecace08cf6349bfd5e93 430966 non-us/net optional ssh_1.2.26-4_i386.deb 33d2642924205944373e7335933874bd 40768 non-us/net optional ssh-askpass_1.2.26-4_i386.deb I guess this will be rejected... where should it go (no, I will not subscribe to debian-policy now...) non-US/main because we all need it? non-US/contrib because it needs rsaref to compile? non-US/non-free because rsaref is also in non-US? non-US/non-free because ssh is non-free Does this mean I need to re-upload it, or will someone else sort it out ? Cheers, Phil.
Re: Use of the -devel-announce list
On Wed, May 12, 1999 at 03:24:06PM +0100, Julian Gilbey wrote: Question: would it be worth making -devel-announce a moderated list? Yes! But I wouldn't want to be the moderator... so maybe your suggestion is enough. Perhaps an auto-moderator, which rejects messages lacking a Reply-To: header (with an informative error message)? -andy -- Andy Isaacson [EMAIL PROTECTED] [EMAIL PROTECTED]Fight Spam, join CAUCE: http://www.csl.mtu.edu/~adisaacs/ http://www.cauce.org/
Re: Uploaded ssh 1.2.26-4 (source i386) to non-US
On Wed, 12 May 1999, Josip Rodin wrote: I doubt it, since the old ssh package is already in place, so this'll probably get overriden. You have a point there... I had this: Installing: apache-ssl_1.3.6.4+1.32-1_m68k.deb to dists/potato/non-US/main/binary-m68k/apache-ssl_1.3.6.4+1.32-1.deb And I got this mail: (new) pgp-us_2.6.3a-5_m68k.deb optional non-us/utils WARNING: Already present in non-free distribution. because pgp is allready in non-US/non-free on pandora? In there, because the licence is clearly not DFSG free. See /usr/doc/ssh/copyright, the very title says: Thanx for the explanation (my question was more theoretical though, I do not maintain any non-US packages). So I will build ssh for m68k and dinstall will move it by itself were it belongs, hopefully. Ciao, Christian.
Re: Release Plans (1999-05-10)
On Wed, 12 May 1999, Sven LUTHER wrote: On Wed, May 12, 1999 at 03:09:02PM +0200, Hartmut Koptein wrote: No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. Exactly. For a PReP bootable CD (which would be nice), you have to lay the first track as a raw PReP bootable image. The second track has your fs in whatever format you want dos/iso/etc. Although this CD will work on other architectures, it will not be bootable unless they have boot schemes which don't conflict with PReP. The problem is that each subarch is too different to have a full-featured unified CD. If we want a unified official CD then it will have to go to the lowest common denominator. Of course, a PPC user can't boot from CD then they have to resort to floppy or network which means we've got to split the rescue disk or fix the libc hack so we can squeeze on one floppy. How hard is maintaining separate bootable CD images for each subarch that can handle booting from CD? We have apus - ? chrp - ? pmac - supports CD booting - how? prep - supports CD booting - as I described. Everything on the fs will be the same at least between subarchs. -- Matt Porter [EMAIL PROTECTED] This is Linux Country. On a quiet night, you can hear Windows reboot.
Re: Release Plans (1999-05-10)
AVC == Aaron Van Couwenberghe [EMAIL PROTECTED] writes: AVC Ok, um, then I will write some scripts today for a AVC slink-gnome-stage-area. ;) There is one already. See the readme master.debian.org/~jim/gnome BTW: compiling gnome is a pain. We _need_ source dependencies ... Everytime I thought I have all the needed stuff, it bombs somewhere (currently it doesn't find the docbook stylesheets - of cause this is reported after all the stuff has been build...) Ciao, Martin
debian-upload-queue in Japan (Re: Homapages in list of maintainers)
At 12 May 1999 08:09:01 +0900, Taketoshi Sano [EMAIL PROTECTED] wrote: I think so. and more, I hope that the site for dupload established in Japan so that we can select the near site to upload our packages. In current standard /etc/dupload.conf contains chiark (uk), master (us?), erlangen (de), and giano (it). I hope that one of the JP's site is registered as the official upload site. But it may takes some effort in JP project also, and I am only just plain member in JP project, so I have to debate about it in JP project also, not only here,,, I've already set up debian upload queue daemon on master.debian.or.jp. It seems to work fine, Susumu Osawa has uploaded aumix package as powerpc binary NMU via this upload queue yesterday:) Now, I'm wondering what nickname is used for this upload queue. Since master-jp is already used for nickname to dupload for JP archives (in Debian JP Project), different name is better to distinguish, I think. Any idea? Regards, Fumitoshi UKAI
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 08:08:06AM -0700, Matt Porter wrote: apus - supports CD booting, but don't know how ? chrp - ? pmac - supports CD booting - how? prep - supports CD booting - as I described. but would it not be nice to but the boot stuff for everyone of this system on one partition and the common stuff on the rest of the CD. Also, we have already two binary cds, maybe it will even grow to three, there is nothing stoping us from making binary-cd1 bootable for prep, the other for pmac and apus, or some other combination ... Friendly, Sven LUTHER
Re: /lib/libNoVersion.so.1
That link suddenly appeared on my system as well, immediately following a apt-get upgrade which I performed yesterday (I'm running potato). I've got no converted RPMs whatsoever (or any other converted formats, for that matter). On Wed, May 12, 1999 at 10:03:22AM -0400, Randolph Chung wrote: In reference to a message from Russell Coker, dated May 12: I have just had this file appear on my system. It is a broken link and dpkg -S doesn't tell me anything about it. It appeared when I installed about a dozen of the latest potato packages yesterday... Does anyone know what it is about? Most likely you installed a package from redhat that is converted with alien. afaik, that's a redhat library, not a part of debian.
Re: Use of the -devel-announce list
On Wed, May 12, 1999 at 03:24:06PM +0100, Julian Gilbey wrote: Question: would it be worth making -devel-announce a moderated list? absolutely. the logo thread on debian-devel-announce seriously pissed me off, because i don't filter the -announce lists with procmail. -vinny
Re: Use of the -devel-announce list
Julian Gilbey [EMAIL PROTECTED] writes: Question: would it be worth making -devel-announce a moderated list? Could we just add some sort of mail filter rule that forces a Reply-To: to be set, and either adds Reply-To: debian-devel or returns the mail to the sender with an explanation if none is set (depending on how BOFHish we want to be).
Haskell in Debian
On Wed, May 12, 1999 at 04:06:36PM +0200, Sven LUTHER wrote: Sorry, you are right, it is the hugs package who is non-free, didn't know there was a free version around. The free hugs98 is pre-release so I'm keeping the stable non-free version around. When hugs98 is released for good (upstream deadline for that is Feb 99), I'll rename hugs98 into hugs and the old hugs shall be forgotten. (Around the same time hugs-doc will disappear too, so we shall hope the ftpmasters will have processed haskell-doc by then...) In related note, according to unofficial information from Simon Peyton Jones (the primary author of GHC), the Glasgow Haskell Compiler (GHC) will become free RSN. Currently GHC has no license. I've tried to bootstrap it but it is so big a beast that I'll probably let it pass. I hope someone else packages it when it becomes free. Most third-party packages for Haskell have no license, which is sad. This includes IIRC GreenCard (a uniform foreign language interface for the more popular implementations) and TkHaskell (a Tk-based GUI library). Somebody should start pestering the authors about this so we'll get a good set of Haskell development tools for woody (or potato if we're lucky). -- Antti-Juhani Kaijanaho A7 [EMAIL PROTECTED] ** URL:http://www.iki.fi/gaia/ ** The FAQ is your friend. Trust the FAQ.
Splitting debian-devel-changes to separate lists
Hi, The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. B. -- B. Warmerdam GNU/Debian Linux [EMAIL PROTECTED], [EMAIL PROTECTED] (Keyid: 10A0FDD1)
Re: Haskell in Debian
On Wed, May 12, 1999 at 07:00:31PM +0300, Antti-Juhani Kaijanaho wrote: On Wed, May 12, 1999 at 04:06:36PM +0200, Sven LUTHER wrote: Sorry, you are right, it is the hugs package who is non-free, didn't know there was a free version around. In related note, according to unofficial information from Simon Peyton Jones (the primary author of GHC), the Glasgow Haskell Compiler (GHC) will become free RSN. Currently GHC has no license. I've tried to bootstrap it but it is so big a beast that I'll probably let it pass. I hope someone else packages it when it becomes free. It is good news though it is only unofficial one. I've tried to build 4.02, it took me 4 hours on my K6-233 box and costed more than 100MB disk. I'd like to apply to become a Debian maintainer and package it, if no one want to take it. Regards, Zhu Rui
Intent to package: theme-convertors
theme-convertors is a package written by myself that will convert themes[1] to .deb files. At the moment, this works on GTK themes and WindowMaker themes. The package includes a Perl library Debian::ThemeConvertors which holds common code to the two convertors, so adding convertors for other things should be easy. I've tested it with tarballs from wm.themes.org and gtk.themes.org. A considerable effort is made to get the layout of the resulting packages looking right, particularly for GTK themes where everyone seems to have a different idea about how the tarball should be laid out... theme-convertors is architecture-independent. Copyright: GPL SRH [1] It's not really limited to themes, and I'm sure people could dream up other uses for it. -- Steve Haslam Debian GNU/Linux [EMAIL PROTECTED] gnome-libs, gnome-core, gnome-control-center, gdm, p3nfs.what, me worry? pgpxLeAnCKmyu.pgp Description: PGP signature
Re: [Vince's cool upload of the month ;] Uploaded wine 0.0.990508-1 (source i386 all) to master
On Wed, 12 May, 1999, Vincent Renardias wrote: This version works well enough to be able to run MS Office's install program and run Excel95 and Word95. (not all of their features are working and there are a lot of painting/refresh bugs, but it's working PrettyWell(tm). Is that Excel95 and Word95, or Excel97 and Word97, I think most people are running the latter (if they have MS-Office). I bet Office 2000 is designed too never work with wine. If you're keeping a DOS partition only for MS Office usage, you'll soon be able to reformat it ;) Format: 1.5 Date: Mon, 10 May 1999 16:14:26 +0200 Source: wine Binary: wine-doc libwine-dev libwine0.0.971116 wine libwine-dbg Architecture: source i386 all Version: 0.0.990508-1 Distribution: unstable Urgency: low Maintainer: Vincent Renardias [EMAIL PROTECTED] Description: libwine-dbg - WINdows Emulator (Static Libraries for Debugging) libwine-dev - WINdows Emulator (Development Files) libwine0.0.971116 - WINdows Emulator (Library) wine - WINdows Emulator (Binary Emulator) wine-doc - WINdows Emulator (Documentation) Changes: wine (0.0.990508-1) unstable; urgency=low . * New upstream release: - Lots of threading fixes. - Start of enhanced metafile support. - Several common controls improvements. - Lots of bug fixes. -- I consume, therefore I am pgp3E51c5NNZr.pgp Description: PGP signature
Re: Use of the -devel-announce list
On Wed, 12 May, 1999, Julian Gilbey wrote: Please can I encourage anyone posting to -devel-announce to ensure that they have set the Reply-To: field to something sensible, and to encourage anyone replying to a -devel-announce posting to check where they are sending their reply. (Hint: -devel-announce is usually not appropriate!) This is meant to be a very low volume announcement list, and it would be good to keep it that way. Question: would it be worth making -devel-announce a moderated list? No, that is not the hacker way, that is the suit way. The solution must be that every time you see a follow-up in debian-announce that should not be there you send a message in private mail, to the author explaining their mistake. They will get a couple of mails telling them not to do it and they won't do it agian. I wonder if you know how ITS stops hackers crashing the system. They had a KILL SYSTEM command that would crash the system. A newbie would find it, run it and the system would crash, everybody would shout at them and they would never do it agian. Nobody got a kick out of crashing the system so nobody did it, except newbies, and they were newbies, so could be forgive, once. -- I consume, therefore I am pgpOgU3YrEgiE.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
At 15:14 +0200 1999-05-12, Sven LUTHER wrote: I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. For power macs, we don't need to worry about bootable CDs, most of them have Open Firmware that is too broken to even be capable of booting from either a cdrom drive or a iso9660 filesystem. The few macs that have reasonable OF should be able to boot from an arbitrary executable residing anywhere on the filesystem. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Splitting debian-devel-changes to separate lists
On Wed, 12 May, 1999, Bart Warmerdam wrote: Hi, The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. seconded -- I consume, therefore I am pgppePN9tDg4H.pgp Description: PGP signature
[Fwd: New nonfree/ hierarchy on CTAN]
CTAN are adopting Debian's definition of free software! (Follow the links in this article, which was [EMAIL PROTECTED] in comp.text.tex yesterday) Jules (Any replies for me to read, Cc: I haven't (yet) resubscribed to -devel) Robin Fairbairns wrote: The CTAN team have been concerned, for some time, about the copyright status of the material held on the CTAN archives. In the course of preparation of the latest TeX Live disc, Sebastian Rahtz compiled a list of the licence status of many available packages, and it is the CTAN team's intention to extend that list to as full coverage of the archive holdings as is possible. In parallel with this work, we have instituted a new hierarchy on CTAN, called nonfree/; it is our intention to move all items, for which there are significant distribution restrictions, to that hierarchy. STRUCTURE The nonfree hierarchy mimics the structure of the main part of CTAN; there are (or may in the future be) sub-hierarchies nonfree/biblio, /fonts, /graphics, /indexing, /language, /support, /systems and /web For each entry in the non-free hierarchy, there is a corresponding entry in the main part of CTAN, which is a symbolic link to the nonfree/ hierarchy. Since CTAN does not index symbolic links, the only appearance that a non-free item makes in the FILES.* files is its instance on the nonfree/ hierarchy. The `quote site index' command uses FILES.byname, so that it will always tell you if the item you're seeking is not free. CRITERIA Licensing conditions that CTAN currently recognises are listed in http://www.tex.ac.uk/tex-archive/help/Catalogue/licenses.html In the terms defined therein, the nonfree/ tree will hold items whose licensing is unknown, nocommercial, nosell, shareware, or other. Notes: 1. CTAN cannot hold matter whose distribution is restricted, anyway: the archive has no control over what its mirrors might do. This is why there is no category `nodistribute'. 2. The `nonfree' licensing category nosource _does_ stay in the main CTAN tree; there are usable items on CTAN whose source is not publicly available, but which are nevertheless freely usable and distributable by all and sundry. 3. We need to treat unknown licenses as nonfree, because of the legal situation in many countries that one is obliged to assume that an author would not wish his/her propertty to be treated as if it were in the public domain. We have, as yet, moved nothing of category unknown to the nonfree/ hierarchy; we will be doing that job later in the year. THE FUTURE The CTAN team are slowly moving items to the nonfree/ hierarchy. This process may be expected to accelerate during the course of this year; in particular, one may expect items of category unknown to be moved starting next month (June 1999). If *you* are an author who has not responded to an enquiry about the status of your stuff on CTAN, we urge you to release a new version which makes its licensing status clear, and to upload that version to CTAN in the usual way (see README.uploads on any CTAN site). Don't forget to mail [EMAIL PROTECTED] -- uploads don't get acted upon without such a message. If you don't do this, and we don't otherwise deduce the status of your stuff, it is liable to be moved to the nonfree/ hierarchy, and to disappear from future CD distirbutions of TeX. OTHER INFORMATION While CTAN is _not_ enforcing an open-source policy, we recommend sites such as http://www.opensource.org/osd.html for discussion of the issues behind software licensing. -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
[OFF-TOPIC] web-discussion/mailing-list/etc package
Hi, Sorry for the off-topic post. A friend of mine needs a software package that does the following: I'm looking to set up a couple of web-based discussions on my box. I want to have a mailing list with archived messages that anyone (or anyone with a password) can read and post to. I'd also like for people to be able to post files to download, and provide attached documentation that appears on the web site. Do you know of any good canned systems the work in Linux for doing this? Any ideas? Thanks, -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
Adding a global UID/GID?
GENERAL QUESTION: What is the procedure for getting a UID in the 0-99 range added to Debian? SPECIFIC QUESTION: I've noticed in the course of setting up a CVS pserver that it is not very easy on Debian, and the default is not secure. I would like to either work with the existing cvs maintainer (Tom Lees) to change the package or else create an add-on package similar to cvsd on freshmeat. In particular, what I would like to see is to have the cvs pserver run under its own UID/GID (as opposed to root). Also, running in a chroot environment would be desirable. Support scripts for easily adding/removing non-system-account cvs users is also a goal. So, the question is: Should this be done with a cvsd.cvsd user in the 0-99 range, or should it use a dynamically assigned UID (100-999)? I noticed we already have users like irc and msql in the 0-99 range. -Mitch -- Democracy is the worst form of government except all those other forms that have been tried from time to time. -- Winston Churchill
Re: Here's my .xsession (was Re: User-selected window-manager in an easy way)
On May 11, [EMAIL PROTECTED] wrote:
# launch the session-controlling process. If it dies, so does the session.
#exec logout-button
exec gnome-session
This is bad. Please try something like:
fxt() { xterm -fg red exec sleep 999d; }
gnome-session || fxt
--
ciao,
Marco
Re: Release Plans (1999-05-10)
Ossama Othman wrote: GNOME has been copied from the staging area into potato. I believe that just about all of the GNOME packages that I copied into Incoming have been installed into the archive. However, at least two packages should get into the archive before the freeze libgtop1 and libghttp1. These are installed now. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Richard Braakman
Re: Release Plans (1999-05-10)
Hi Richard, I'm cross-posting to debian-gtk-gnome since we are trying to organize an effort to update GNOME for slink. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? -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: Release Plans (1999-05-10)
Richard Braakman [EMAIL PROTECTED] writes: Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. The current plan, as I understand it, is to build GNOME 1.0 debs for slink, and turn them over to the GNOME folks for distribution from ftp.gnome.org. This was, in fact, one of the original motivations for setting up the slink staging area. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Install-time byte-compiling: Why bother?
On Sun, May 09, 1999 at 02:31:39PM +0100, [EMAIL PROTECTED] wrote: On another machine, this a 300Mhz K6-2, I invoked W3 in Xemacs20 (using lisp interaction mode to eliminate the wait for the user to enter a URL). In this case it was 10 seconds for .elc files, 15 seconds if it had to byte-compile the .el files themselves. This was Interesting! Where did you get that version of Xemacs? My xemacs does not byte-compile the .el-Files on loading (that would take REALLY long) but instead slows down a bit. I don't think it's valid to compare times for LOADING the files. It's quite simple to load the .el-Files. Try to run some lisp code doing heavy stuff - e.g. opening a 200k html file with w3. cu Torsten
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 02:42:16PM -0500, Ossama Othman wrote: Hi Richard, I'm cross-posting to debian-gtk-gnome since we are trying to organize an effort to update GNOME for slink. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? Opinion: probably not. That's what a release is.. that's what next versions of releases are for... Security fixes are a special issue but 'the next/latest/newest widgit' are not.. -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgpu1f4QXZTjf.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
Hi Darren, On 12 May, Darren O. Benham wrote: On Wed, May 12, 1999 at 02:42:16PM -0500, Ossama Othman wrote: Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? Opinion: probably not. That's what a release is.. that's what next versions of releases are for... Security fixes are a special issue but 'the next/latest/newest widgit' are not.. No problem here. Will we then just make the debs available to the GNOME for folks to distribute, as Chris mentioned? -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: Release Plans (1999-05-10)
It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. Also, for potato, since it WILL be glibc 2.1 based, I suspect a large number of people would want versions of XFree, gnome, and other packages without having to upgrade their systems. By setting up an extension to our current directory structure for updates, we make it VERY simple for people to add these in. I THINK it might also make it easier to release maintenance releases in this manner. Simply have all the updated packages in the updates section. If apt and dselect do their jobs, it should grab the proper NEWer version of the package. Dave On Wed, 12 May 1999, Darren O. Benham wrote: Date: Wed, 12 May 1999 13:10:53 -0700 From: Darren O. Benham [EMAIL PROTECTED] To: debian-devel@lists.debian.org, debian-gtk-gnome@lists.debian.org Subject: Re: Release Plans (1999-05-10) Resent-Date: 12 May 1999 20:13:09 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; On Wed, May 12, 1999 at 02:42:16PM -0500, Ossama Othman wrote: Hi Richard, I'm cross-posting to debian-gtk-gnome since we are trying to organize an effort to update GNOME for slink. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? Opinion: probably not. That's what a release is.. that's what next versions of releases are for... Security fixes are a special issue but 'the next/latest/newest widgit' are not.. -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgpSKcGqpXzkD.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 02:06:24PM -0700, David Bristel wrote: It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. Also, for potato, since it WILL be glibc 2.1 based, I suspect a large number of people would want versions of XFree, gnome, and other packages without having to upgrade their systems. By setting up an extension to our current directory structure for updates, we make it VERY simple for people to add these in. I THINK it might also make it easier to release maintenance releases in this manner. Simply have all the updated packages in the updates section. If apt and dselect do their jobs, it should grab the proper NEWer version of the package. Propose it on -Policy and be sure the cc' the ftpmasters. An issue to consider is manpower. Since most of the maintainers will up to Potato, who'll compile these new packages/updates for slink? -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgptqq525NlVx.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
In article [EMAIL PROTECTED], Richard Braakman [EMAIL PROTECTED] writes Ossama Othman wrote: GNOME has been copied from the staging area into potato. I believe that just about all of the GNOME packages that I copied into Incoming have been installed into the archive. However, at least two packages should get into the archive before the freeze libgtop1 and libghttp1. These are installed now. I assume the delay with libgtop1 was that it was a new package? If so, please remove libgtop0. Thanks -- Ian Lynagh - [EMAIL PROTECTED] http://www.lynagh.demon.co.uk/ Just because you're paranoid, it doesn't mean they're not out to get you.
Re: Release Plans (1999-05-10)
Hi, On 12 May, Ian Lynagh wrote: I assume the delay with libgtop1 was that it was a new package? If so, please remove libgtop0. Right. That's what Guy told me. You should probably e-mail the ftp masters about your desire to remove libgtop0 from the archive. -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
Slink compiles [was: Re: Release Plans (1999-05-10)]
On Wed, May 12, 1999 at 02:40:33PM -0700, Darren O. Benham wrote: Propose it on -Policy and be sure the cc' the ftpmasters. An issue to consider is manpower. Since most of the maintainers will up to Potato, who'll compile these new packages/updates for slink? Can't autobuilders do it (with a source-only upload)? -=- 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
doc-base and obnoxious unknown format warnings
I've been noticing that, even though we're all encouraged to use doc-base nowadays, that doc-base emits noxious and obnoxious warnings whenever it sees a format it doesn't recognize. I've just adapted libgtk1.2-doc to use doc-base, and on EVERY install or removal, I get: Setting up libgtk1.2-doc (1.2.3-1) ... warning: ignoring unknown format `texinfo' at /usr/sbin/install-docs line 627, IN chunk 10. warning: ignoring unknown format `info' at /usr/sbin/install-docs line 627, IN chunk 13. warning: ignoring unknown format `texinfo' at /usr/sbin/install-docs line 627, IN chunk 10. warning: ignoring unknown format `info' at /usr/sbin/install-docs line 627, IN chunk 13. warning: ignoring unknown format `linuxdoc-sgml' at /usr/sbin/install-docs line 627, IN chunk 10. warning: ignoring unknown format `linuxdoc-sgml' at /usr/sbin/install-docs line 627, IN chunk 10. warning: ignoring unknown format `linuxdoc-sgml' at /usr/sbin/install-docs line 627, IN chunk 10. warning: ignoring unknown format `linuxdoc-sgml' at /usr/sbin/install-docs line 627, IN chunk 11. Ugh! And on an upgrade, I get this spam *TWICE*. Is there any way we can make the default for doc-base to *not* warn on these unknown formats? Frankly, it's just ugly as all get-out. :) Ben -- Brought to you by the letters Z and F and the number 9. HEY YO GYS! Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
Re: Debian coding style?
Query, is there actually a coding style guideline for debian stuph?
Basically I'm with the Corel Linux group and this is what the Corel
Linux Coding guidelines say... (follows). A few note-worthy ones are:
- tabs: 2 spaces
- curly braces alway on next line
ie if (...)
{
}
else
{
}
- hungarian notation
Will the Debian community be excrusiatingly unhappy with this?
I believe they will be.
I have seen many bad or ugly coding styles and a very few good ones.
One of the best I've ever seen is that used for Tcl/Tk C source code.
Please have a look at it. Tcl C code is well indented, easy to read
and uses reasonable conventions about variables functions names and
comments.
3. Tabs should be set to 2, and they should be kept as tabs, no spaces
please.
Absolutely not. Almost all text processors have 8 spaces tabs. Any other
size means only a lot if troubles to all develpers, except those at Corel.
I usually use 4 space indentation with 8 spaces hard tabs.
4. Code width: The complete line of code should be visible without having to
scroll horizontally - i.e. it should normally not pass the 78th column.
I agree, it makes code easier to read.
5. Naming conventions:
...
Hungarian Notation:
...
Nobody except Micro$oft uses that. Again, compare a source file in Hungarian
notation with a Tcl C source file.
* Magic numbers must not be embedded directly in the source code. Use a
const int variable to hold the magic number rather than a #define.
I totally agree.
7. Comments : Please comment your code, it makes everyone's life easier.
...
I agree. Comments are as important as the code itself. Again, see Tcl style.
But please use /* */ instead of //. It is far easier to read.
10. Function/method size: bigger is not better. Functions and methods should
be kept to a maximum of 40-50 lines. Larger methods should be broken down
into several smaller methods.
This could be accepted as a guideline but not strictly enforced. Sometimes a
long function can be better, faster or easier to write than many small ones.
And if you have many while/if/else the effective code size could be not more
than 20-25 lines, excluding the curly braces...
11. Curly braces
a) location must be on the next line and right underneath the 1st coding
column of the line directly above it.
This is good for functions but a waste of space for if/for/while constructs.
Unfortunately not everyone can switch to a 1600x1200 monitor while coding.
b) All statements following if, while, for, ... etc. must be enclosed within
braces even if it is only 1 line.
I like this, but many peole don't agree. I would say 'should'.
12. Spacing
a) there must be spaces separating each binary operator and each keyword.
eg. a = b; and not a=b
I like also this.
b) blank spaces should not be left between method/function names and the
opening bracket.
I agree.
c) blank spaces should not be left immediately after an opening bracket, nor
immediately before a closing bracket
eg. DoIt(this); and not DoIt( this );
if (test) and not if ( test )
IMHO a waste of space in general. Useful only in some cases.
e) multiple parameters to methods/functions should be separated by a comma
followed by a single blank space (not a tab)
eg. DoIt(this, that, theOther);
Ok.
g) leave blank lines between sections of code. Each major section of code
should include a comment explaining what it's purpose is.
I agree.
14. Compilation conditionals, with the exception of debug code noted above,
should be avoided since they make the source code difficult to read and
maintain. Old or unwanted code should be deleted from the source files prior
to check-in. Source safes history feature can be used to retrieve an old
version of the file if the old code is ever required again.
Compilation conditionals can't be avoided if you want your code to be
portable to multiple platforms. Old code should really be dropped.
16. Goto statements should not be used.
In generally they should not be used, except for jumping to exit code in
case of error. There may be other useful exceptions too.
17. Return: functions and methods should be structured to have a single
return.
If you forbid jumps but want a single return you will end up writing very
contorted code. Both jumps and multiple returns can be good if used with
caution.
19. Comparisons for equality against a constant value should list the
constant value first. Its easy to miss one of the equals signs - this way
the compiler will catch it if you do.
eg. if (-1 == m_nResult) rather than if (m_nResult == -1)
Reasonable from a software engineering point of view, but very unnatural
to read for humans. I prefer the contrary and let the compiler warn me in
case of suspicious statements. Let the computer do the job for you.
20.
Intent to package: plib (was: request for package)
Hi Can someone please package plib, which is Steve's Portable Game Library. It has a LGPL license so it can go into main without problem. I grabed the sources and had a look at it. As it is my first package with shared libraries and -dev and -doc and such it first tried it and it seems to work. There were no real problems (AFAIK). The packages are in incoming. The reason I want this is so I can try `Tuxedo T. Penguin, A Quest for Herring' (http://www.woodsoup.org/projs/tux_aqfh/). If someone can package that as well I'ld be really happy :) I'll have a look at it too. Regards, Philipp
Re: Install-time byte-compiling: Why bother?
Torsten Landschoff writes: [EMAIL PROTECTED] wrote: On another machine, this a 300Mhz K6-2, I invoked W3 in Xemacs20 (using lisp interaction mode to eliminate the wait for the user to enter a URL). In this case it was 10 seconds for .elc files, 15 seconds if it had to byte-compile the .el files themselves. This was Interesting! Where did you get that version of Xemacs? My xemacs does not byte-compile the .el-Files on loading (that would take REALLY long) but instead slows down a bit. Obviously I've misunderstood the behaviour of Emacs here - I'd assumed that the internal form was the same regardless of whether one got there via byte-compiling or not. Apparently this isn't the case! I don't think it's valid to compare times for LOADING the files. It's quite simple to load the .el-Files. Try to run some lisp code doing heavy stuff - e.g. opening a 200k html file with w3. Ah yes, that does make a significant difference - 67s with *.elc versus 120s with *.el for a 100613 byte HTML file. Then again, neither time is remotely tolerable for web browsing, given that Lynx and Netscape both render the same web page in less than a second! The point is well made, though. ttfn/rjk
Re: Homapages in list of maintainers
Hi ! In article [EMAIL PROTECTED] Fumitoshi UKAI [EMAIL PROTECTED] writes: I can volunteer to do it, if it is really needed and anyone object to it. I've been maintain Debian JP machines, ftp archive, web server, mailing-list and Debian official mirror in Japan about two years or three. Thank you for your proposal :). I think it is required very much to get the Debian project to be more global organization as fast as we can, because if more people can join the project smoothly, the project can get more resource to do various task. if someone has the required condition to pass the verification by the New Maintainers Group, I can not find the merit of keep him (or her) in the long waiting queue. If the problem is only related to the human power, the action to do should be to increase the member of the Group, not to keep the queue longer. Adam Di Calro told Remember that approving new maintainer is a very _sensitive_ area, and I think it should be, but if the members in the Debian Project want to make this project to be true global and universal, an action to make the waiting queue shorter should be taken anyway now or in the near future. I am eager to know if anyone has objection. -- Taketoshi Sano: [EMAIL PROTECTED]
Re: doc-base and obnoxious unknown format warnings
Ben Gertzfield wrote:
Is there any way we can make the default for doc-base to *not* warn on
these unknown formats? Frankly, it's just ugly as all get-out. :)
--- /usr/sbin/install-docs Sat Jan 2 01:48:28 1999
+++ ./install-docs Wed May 12 15:27:12 1999
@@ -624,7 +624,7 @@
} elsif ($$format_data{'format'} eq 'text') {
# no additional fields required
} else {
- warn warning: ignoring unknown format `$$format_data{'format'}';
+ warn warning: ignoring unknown format `$$format_data{'format'}' if
$ENV{DOC_BASE_GRIPE};
}
--
see shy jo
Re: doc-base and obnoxious unknown format warnings
In message [EMAIL PROTECTED] you wrote: I've been noticing that, even though we're all encouraged to use doc-base nowadays, that doc-base emits noxious and obnoxious warnings whenever it sees a format it doesn't recognize. I've just adapted libgtk1.2-doc to use doc-base, and on EVERY install or removal, I get: [...] Ugh! Geeze -- ok, I'll fix it tonight. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
