Re: default file perms
b4f978d71d6dd8d4558632b5a185f28d 37760 root root 755 r/bin/ls (with type being 'r' for regular files, 'b', 'c', 'p', 'l' for (respectively) block and character devices, pipes, links). It might be worth adding a type for control files, to make it easier to spot the difference between a corrupt binary, and a file that has been edited by the sysadmin. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs-buildpackage: CVS trees and automated builds
Does this mean that debian is finally going to have a make world, and also a CVS scheme just like the bsd's? Finally! Woohoo!!! Heres to Debian, the finest Linux distribution : Now, if only we could configure the kernel at boot time like in bsd Heck, with the .deb format, this is gonna go bsd one better, with dependancies and things On 28 May 1997, Manoj Srivastava wrote: So, I can compile all the packages I want by just running: __ cd /usr/local/src/Work; for i in *; do (cd $i; cvs-buildpackage -rsudo ) done -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 FAQ
Hi, My contention is: if we are talking about a program that needs kernel headers, and can't be satisfied with the headers included in the libc5-dev package (which corresponds to 2.0.29, or something), that means we are talking about a program that needs some very specific kernel data structures, and can't do with the definition of that data structure included in the libc headers. I assume that the program uses this version specific data structure (or else why require to see this specifically?); that means it uses it in interaction with the kernel in some way. So, since it can't use the definition contained in the headers of a different kernel, as this definition would be different and possiby meaningless, Therefore running this program on any other kernel than the one it was compiled for is meaningless, and would probably cause it to crash and burn. If at this point someone says it is not so, that it can run on any kernel, then I say it should not require the headers of the kernel sources on the developers machine (which may or may not correspond to the running kernel) as opposed to the headers from 2.0.29 included in libc5. In any case, I shall not include directions about the net headers, since any one maintaining a programme that requires such an intimate iteraction with the kernel should have the knowledge to affect this in a version independent fashion. Also, any programme this closely connected to the kernel version should have the version of the kernel it was compiled for in the name, a-la-pcmcia-cs, and should take extreme care on *every* invocation that the current kernel version is the same as the one it was compiled for, in case the bug is subtle and not easy to detect. manoj -- Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 FAQ
Hi, Mixing user domain and kernel domain stuff is a really bad Idea, but you don't have to take just my word for it. I already have posted the FAQ once today, and I don't want to do so again: Please read the libc FAQ (or email me and I will send you a copy). The bottom line is: if a program needs kernel header, the chances are that the program, or the design of the program, is broken. (It is not as though the kernel data sructures change every day [oh the good 99.14 days]). If you are talking about the few that are really that version dependent, then they are compatible with just *one* kernel version, and have to abort if *any* other version is running. Bernd == Bernd Eckenfels [EMAIL PROTECTED] writes: Bernd Hello, My contention is: if we are talking about a program that needs kernel headers, and can't be satisfied with the headers included in the libc5-dev package (which corresponds to 2.0.29, or something), that means we are talking about a program that needs some very specific kernel data structures, and can't do with the definition of that data structure included in the libc headers. Bernd I think libc6 will rebuild the .../sys/ headers with scripts Bernd from crrent kernel source. If even libc6 depends on this, why Bernd not use ith with libc5. Please re-read the FAQ. The why is answered there. Bernd Simple Example: Bernd /* -- new Socket ioctl included in kernels 2.1.20++ -- */ define SIOC_BLAFASEL 5 Read Linus's example. Bernd If I want to use new feature BLAFASEL i will have to issue an Bernd ioctl 5 to the kernel. If I hardwire IOCTL 5 in my program i Bernd will be able to compile it independend from kernels versions = Bernd 2.1.20, but i wont be able to be sure that = 2.1.21 will Bernd redefine the ioctl, or even worse, remove it. Its impossible to Bernd refuse to run on 2.1.21++ Kernels, since I would havbe to Bernd release new tools every day. Best thing i do is: Bernd use BLAFASEL if it is defined, dontuse it if not. Then the Bernd program will compile in 2.1.20 (unable to use the new feature) Bernd and compile with 2.1.20 (enabled to use the feature as long as Bernd it is there, even after renumbering). Thats what the headers Bernd are for. So, you compile it on your machine on 2.1.20. I try to use this. Should it run? What version am I using? or is the user to recompile (!!) it for every kernel upgrade? Bernd BTW: it seems to be very easy to port net-tools for exapmle to Bernd libc6, but the reason fr this is, that the headers will include Bernd all the kernel dependend stuff in a version depending Bernd manner. (only the release cycle of libc6 has to be more faster Bernd to include all new features from new kernels). That again is retrogessive. manoj -- Faith in a holy cause is to a considerable extent a substitute for lost faith in ourselves. -- Eric Hoffer Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: default file perms
In message [EMAIL PROTECTED] you write: |--==_Exmh_263623679P |Content-Type: text/plain; charset=us-ascii | | |dpkg-cert already does something like this. Klee is going to fold the |capabilities of dpkg-cert into dpkg, so I think a solution is on |the horizon. :-) PLEASE PLEASE PLEASE! If you are allready at it - it would be nice to be able to find files which do NOT come from any package. This will make it much easier for the person in charge to find sniffer log files and binaries, and make it harder on the cracker to conceal them. Thanks, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL [EMAIL PROTECTED] | -- Anonymous -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: default file perms
In article [EMAIL PROTECTED], Amos Shapira [EMAIL PROTECTED] writes: PLEASE PLEASE PLEASE! If you are allready at it - it would be nice to be able to find files which do NOT come from any package. This will make it much easier for the person in charge to find sniffer log files and binaries, and make it harder on the cracker to conceal them. Less paranoid-ly, it will also be useful for people upgrading to debian from another distribution.
Re: base-files does not create /usr/local directories
On Wed, 28 May 1997, Brian White wrote: In fact, as part of the Deity project, I'd like to do something a little more elaborate. I'd like to be able to remove or change any arbitrary path. (This was originally Behan's idea, actually.) Ok, then I'd suggest I change the proposed section in our Policy to state that currently, directories in /usr/local have to be created in postinst (that's the only possibility _now_) but this will change in the near future when this feature is added to dpkg/deity. Well, since it's too late for this to have any effect on Bo and this should be easily done before Hamm gets released, I don't see how this will accomplish anything as far as the public user base is concerned. It's just a matter of documentation. Creating the empty directories in the postinst scripts is what our packages are currently doing since this has been proposed on debian-devel. Thus, I want to document this implicit policy. With the note I added about the new feature maintainers should realize that our current solution is just a workaround. If dpkg/deity has this feature implemented, I'll change the policy to the new scheme. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED] for a logo! Have a look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 FAQ
-BEGIN PGP SIGNED MESSAGE- On 28 May 1997, Manoj Srivastava wrote: The bottom line is: if a program needs kernel header, the chances are that the program, or the design of the program, is broken. I must second Andreas here. The ISDN stuff is an exception. There is active development in the ISDN area. The device driver should have made it into the 2.0.30 kernel, but didn't because of an error of the kernel source maintainers. It contains stuff there to stay, but the ISDN utilities need this stuff now. In short: Future (stable and unstable) kernel versions will contain the data-structures and definition that isdnutils is needing now. The utilities are just a bit ahead of the kernel releases, but not because of instability but because of mistakes on part of the kernel source maintainers. This is the exception Andreas asks for. Nils - -- \ /| Nils Rennebarth --* WINDOWS 42 *-- | Schillerstr. 61 / \| 37083 Göttingen | ++49-551-71626 Micro$oft's final answer | http://www.nus.de/~nils -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQB1AwUBM41XV1ptA0IhBm0NAQF8LAMAkpmEsCc7KdoQW9jhbUn1Y2gBBM3p52wu IgNWA6T2dVIwu+aGdSTLrI854IIJgy7TRJsCVniyvE/MQMTf/xoQRJv9LOAR5WRH YFpLY12dFdLLmoxc9IVUgwZfRZwDnxQ3 =9WdC -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sysvinit and System.map (Was: dangling symlink System.map)
-BEGIN PGP SIGNED MESSAGE- On 28 May 1997, Guy Maor wrote: Yann Dirson [EMAIL PROTECTED] writes: BTW, psupdate is the only program I can think about using System.map. Are there any other ? klogd ksymoops Mike -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBM41TtkAgIJ53sbT9AQGMEQP/Tp7+L1pxKdi5U7daHbCVZrgbmlg4+9YC zsSCMdQuKZKtkGuVW7LyNxAEIvAk/2yBW7e2Ync09XiS/l0ojXYgaKvzC8pd4YJN PJZDGdLwL4Q6l9yWHXNL7Kkl3KqRSyqKJuR0F41pDSHYutML4e1z1pK8dK4KKZXA +GuHafhUgeE= =TE/F -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: long list of give away or orphaned packages
[EMAIL PROTECTED] (David Welton) wrote on 28.05.97 in [EMAIL PROTECTED]: While it would be nice if new developers took over some orphaned packages (I plan to), unloading a package on someone that they have no interest in, is, IMHO, a bad thing. If they are personally interested in it, they are more likely to understand it well, keep it up to date, and release timely bug fixes. Another point - I've always wanted to take over some orphaned package(s), but I wanted to first, learn the basic stuff with the packages I wanted to do (that's more-or-less done), and second, get my system in a somewhat more usable state (currently, the main problem is much too full disks, which makes development a real pain, and which will probably change shortly after the release - I'll then be able to get rid of buzz [which I need because our servers still run it] and rex, because I'll install bo on those servers). MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: policy about putting packages into frozen ?
On Wed, 28 May 1997, Andreas Jellinghaus wrote: hy. what is the policy about putting packages into frozen ? AFAIk only bug fixes are allowed. my problem is the isdn package : the new version was released (beta1) this week, and it was tested a long time (public cvs tree). now it has a documentation (not all binaries but at least some), some new features and a lot of bugs fixed. the old release is nearly unusable (the kernel driver was fixes in 2.0.29 and again in 2.0.30, the old isdn utils won't run with the new device driver, but using old kernels isn't a good thing in this case.) so : am i allowed to upload the package into frozen (i will build it these day, upload it into unstable, and beg some isdn users to test it). if there are no major problems, it should go into frozen (the old package is nearly unusable and buggy). I'm not sure if it's wise to replace the isdn packages in frozen now. This will surely delay the release (and I don't think Brian would allow this anyways :-) Instead, I suggest to - remove the isdn packages from frozen - upload fixed isdn packages into some other directory on ftp.debian.org, say project/untested/ - add a note to some README of 1.3 that Debian 1.3 does _not_ include the isdn packages, but a untestet version is available in the project/untested directory - introduce the new isdn packages in Debian 1.3.1 (cf. current discussion in debian-private) and mention this in the README Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
Brian White [EMAIL PROTECTED] writes: We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. I need a shared CVS repository for boot-floppies. Especially people who do the porting to other architectures should be able to merge their changes wtihout needing to disturb the primary maintainer. Is there a way to restrict the people who can write to the repositroy part of one package? Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. OpenBSD offers anonymous CVS ; you could try to ask them. I think that Debian's CVS repository should be located on a well-connected site; ISDN isn't enough. Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Conflict between Packages file and actual files
[EMAIL PROTECTED] (Kai Henningsen) writes: I've since seen that ftp.debian.org obviously mirrors somewhere around 19:40-20:50, local time for master, while the maintenance scripts run somewhere in the 11:50-13:40 range, again local time for master. ftp mirrors twice a day at 9 and 21 master time (according to http://www.cc.gatech.edu/linux/ ), and master runs its scripts at 11:52 and finishes around 13 or 13:15. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: long list of give away or orphaned packages
Brian White [EMAIL PROTECTED] writes: the list of debian packges needing a new maintainer is growing all the time. so - what about removeing some packages, if they are no longer maintained, or (better) moving them into section contrib (or a new section orphaned ?). There is a project/orphaned directory where things can be put when no longer supported. This will not be part of the distribution but rather a holding place for packages so that the work done on them does not simply get lost. I just added an extra section to the list that mentions the orphaned packages. It is incomplete ... -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 FAQ
Hello, I must second Andreas here. The ISDN stuff is an exception. Oh come on, there are millions of exceptions. The KErnel Development has never stoped and will never stop. There is a lot of redesign goiug on: new routing, new address families, new arp, new console, new device drivers, new memory management, new ACL support, new filesystems, new privelege support, RT support... all this stuff will come and without access to the kernel headers you always have to wait for the next libc release (which actually depends on the fact that the libc ppl actually know what they have to support). I wont speak about patches to the kernel which are not in the mainstream source. I agree that it is a very good idea to have a stable API, but on the other hand I dont see anything wrong with relying on kernel headers for all those little kernel tools which are exceptions. The only important thing is, that the normal libc header do not rely on kernel headers. Then you can compile all applications which dont need to know kernel details, and only those tools who include linux/.. will break. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +4972573817 BE5-RIPE (OO) If privacy is outlawed only Outlaws have privacy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: Policy for arch specs
Hi folks! As I'm working on a new Policy I'm handling the request to include a policy for correct architecture spec strings. However, I've discovered _several_ threads here on debian-devel without any (obvious) results. Is it correct, that we are currently working on ports to the following platforms (the abbrevs should be the ones that dpkg is using in the file names): i386 alpha arm m68k powerpc sparc Are these correct (i.e. not ppc) and is this list complete? Next step: GNU's configure utility. I thought that we had agreed on using i386-unknown-linux (and similar for the other architectures), but then I had just discovered that GCC uses /usr/lib/gcc-lib/i486-linux/2.7.2.1/ ^^ (first it says i486 instead of i386, second it ommits the unknown). (The reason we didn't choose i386-debian-linux is that we wanted our utilities to be compatible with other distributions.) Any comments, please. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. I need a shared CVS repository for boot-floppies. Especially people who do the porting to other architectures should be able to merge their changes wtihout needing to disturb the primary maintainer. No problem. Just mail me a list of the developers and the name of the project and I'll set it up for you. Things are pretty hectic right now and I haven't automated this process, so it may take a couple days for me to get it done. Is there a way to restrict the people who can write to the repositroy part of one package? For now, I'll set it up so only people in the group you mail me can write to it. Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. OpenBSD offers anonymous CVS ; you could try to ask them. I've passed this on to the CVS maintainer and asked him if he could include those patches in the Debian package. I think that Debian's CVS repository should be located on a well-connected site; ISDN isn't enough. Somebody is free to take it if they want. I think you overestimate the amount of bandwith used, though. Unless we're archiving the entire source tree with all developers using it, I sincerely doubt there will be any problems. Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.02. For this and more, visit http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Consultants list for Debian GNU/Linux
Behan Webster wrote: I've just volunteered to maintain the list of consultants wanting to offer paid support to people running debian systems. I am unaware of anyone else currently doing so. If someone is already doing such, please contact me. Once this list is assembled, it will be put on both the debian web site and be added to the Debian 1.3 CD image that is to be distributed. If you wish to be listed as a Debian third-party consultant, please email me the following information: - Your name - Your address (city and country is all that's necessary) - Your email address - Your phone number (International phone number(1) please) - Your fax number (International phone number(1) please) - Url to your web page - Fees, charges, rates, terms, etc. (1) By International phone number, I mean a phone number that can be used to reach you from any country. For example, my phone number would be: +1-613-224-7547 I forgot to mention, please list your consultant fees in both US dollars and your local currency. (of course, if you are based in the US, listing your fees only in US dollars is sufficient. 8) ) Wow. I've already received a reply since I sent my last post! 8) Thanks, Behan Webster (Debian Consultant list maintainer) -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Andreas Jellinghaus [EMAIL PROTECTED] writes: great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? Some problems arise: Should this CVS repository be mandatory, i.e. does every Debian package have to be there? How much disk space will this take ? this could make some things much easier (i don't want to download the whole source and diffs, to look at two or three files). also it would help to coordinate updates (think of the menu package - this way we could have send diffs direct to the maintainer). My favourite example ;-) So I'll repeat this: IMHO Currently the overhead of fixing a bug and publishing the fixed version is too high. For unstable it would be enough to check-in the fix (e.g. an added menu file, a spelling-fix). Please note that the procedure for stable might be different. there are also situations where several developers have to work together. E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. (Another example: We already used a CVS repository on master for the FAQ.) Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
DF == David Frey [EMAIL PROTECTED] writes: :: Then I have a Print key, Scroll-Lock, and Pause. All :: three keys don't have an effect in my X configuration--on the :: console Scroll-Lock starts/stops terminal output, just like :: C-S and C-Q. Is there any useful meaning for Print and :: Pause in Linux? DF: Yes they may the registers, task list etc. and may switch DF: from/to the last used console. There is another possible usage -- switching between different keyboards. For example Czech Linux users usually use one of these keys for switching between US keyboard (when programming) and Czech keyboard (when writing texts). I think the best what to do with these keys is not to assign anything to them and left them as free function keys for users. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Sven Rudolph writes: Andreas Jellinghaus [EMAIL PROTECTED] writes: great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? Some problems arise: Should this CVS repository be mandatory, i.e. does every Debian package have to be there? How much disk space will this take ? Don't seriously bother about disk space. Debian has a fond of money from which additional disks could be paid. But a problem that I see is that it would be good if we could have _some_ mirrored cvs archives, i.e. there are a lot of european maintainer and it does make sense if we have a master cvs server cvs.debian.org and a europe/ german secondary. I don't know if and how we could arrange that uploads reach the master, too. also it would help to coordinate updates (think of the menu package - this way we could have send diffs direct to the maintainer). My favourite example ;-) And everyone would be able to get an older version than the actual, too. My favourite example: just after setting up an exchange system for my server a friend of mine encountered that the new uucp package was unusable, if I had installed it, the result would be horrorous (sp?). So I'll repeat this: IMHO Currently the overhead of fixing a bug and publishing the fixed version is too high. For unstable it would be enough to check-in the fix (e.g. an added menu file, a spelling-fix). Please note that the procedure for stable might be different. Hmm, where is the change? You still have to publish the fixed version, haven't you? Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / This copy of Netscape has expired. -- Netscape / /Ein weiterer Grund Mosaic zu benutzen. :-( / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Andreas Jellinghaus [EMAIL PROTECTED] writes: great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? Some problems arise: Should this CVS repository be mandatory, i.e. does every Debian package have to be there? Definitely not - that would be a waste. Most packages are pretty simple, so having a shared CVS isn't all that useful for those packages. But it might be nice to be able to add an arbitrary package to the repository via a CGI script or something like that. Cheers, - Jim pgp2C2rx4h4bm.pgp Description: PGP signature
Re: Using CVS for package development
E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. What provision do you suggest for code-review? It's important for things like boot-floppies where a patch for one architecture, done carelessly, might break another. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
= Should this CVS repository be mandatory, i.e. does every Debian = package have to be there? A brief word of warning... (I tried CVS on dpkg a while back) The natural CVS model is to name the directory for the package, for example .../dpkg/ and relegate the version numbers to tags. At least one package (dpkg) uses its directory name in such a way that when the directory is .../dpkg/ the build fails, while it works when the directory is a versioned one, .../dpkg-1.2.3/. -Paul Bame -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
[EMAIL PROTECTED] (Bruce Perens) writes: E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. What provision do you suggest for code-review? It's important for things like boot-floppies where a patch for one architecture, done carelessly, might break another. Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. This mailing list could be used as target for the bug reports against this package. Regarding stability: We will need at least two branches: for stable and for unstable. When some people cooperate on porting to a specific architecture and this port does not work yet, they could create an extra branch. (Usually this won't be necessary.) Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. The way we are currently doing it here (at Pixar) is that nobody checks in an un-reviewed patch, even if they do have commit privilege. Anyone with commit privilege can review it for you and give you an OK to check it in, but it takes two people. It tends to make us think a bit harder about what we are doing. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Mark Baker wrote: In article [EMAIL PROTECTED], Tom Lees [EMAIL PROTECTED] writes: the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And if you're not very careful it does silly things if the scripts have been modified significantly. So you do something like:- BLAH=something # configtool=yes Then, if someone modifies the scripts, they make sure that that particular line is still there, or remove the configtool=yes if they don't want it. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
[EMAIL PROTECTED] (Bruce Perens) writes: Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. (And the CVS commit messages are sent to this list.) The way we are currently doing it here (at Pixar) is that nobody checks in an un-reviewed patch, even if they do have commit privilege. Anyone with commit privilege can review it for you and give you an OK to check it in, but it takes two people. It tends to make us think a bit harder about what we are doing. We could implement this policy for the stable branch, but for the development branch it means much work due the more frequent changes; and the latency for getting a change distributed is high again. (Please note that even my first proposal doesn't make anything worse than it it is done currently. Current procedure is that one person makes a change, releases it (including the binary package). And then other people can review the change; I believe this almost never happens.) Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Sven Rudolph writes: Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. This mailing list could be used as target for the bug reports against this package. Which brings me back to the point of [EMAIL PROTECTED] or [EMAIL PROTECTED] where the actual maintainer can modify the content of that alias by using his account on master and a feature of qmail. $package will point to [EMAIL PROTECTED] for instance. The aliasfile could be generated by a cronjob via examining the most recent Packages file. Comments? Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / This copy of Netscape has expired. -- Netscape / /Ein weiterer Grund Mosaic zu benutzen. :-( / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
anyone packaged/ing vice (comodore emulator) ?
hy. i read the announcement, compiled it for local use and it's great. has anyone packaged vice, or is doing this ? if not, i will do it. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Thu, 29 May 1997, Christian Schwarz wrote: Is it correct, that we are currently working on ports to the following platforms (the abbrevs should be the ones that dpkg is using in the file names): i386 alpha arm m68k powerpc sparc Are these correct (i.e. not ppc) and is this list complete? Correct for powerpc. Didn't know someone was working on ARM(who?) Cordialement, -- - ** Linux ** +---+ ** WAW ** - - [EMAIL PROTECTED] | RENARDIAS Vincent | [EMAIL PROTECTED] - - Debian/GNU Linux +---+ http://www.waw.com/ - - http://www.debian.org/ |WAW (33) 4 91 81 21 45 - --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
There actually is a packages.debian.org domain aliased on master, I had problems making it work because darned qmail won't parse a full RFC822 address on the command line (it wants you to remove the comments). If someone wants to spend some time on a simple mailer hack, you can make this work. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Man-Db and Man both in Frozen???
Hi, There appears to be a package man in frozen that shouldn't be there since man-db is the new name for that package. Somebody needs to take it out; otherwise, it is confusing to users. John -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: long list of give away or orphaned packages
On a related note, games. Games are important. Please please please dont reject someone who wants to package up a game. Thats one of the things I like about debian, it has so many games. I first got mirrormagic working under debian... And I hope to see abuse.svga working again too now that he sources are available. Games are the best and easiest way to have your first real package, and its the most exciting (for a new developer anyways ;)) And, right on cue... Hi! I subscribed a few days ago, (and have been somewhat overwhelmed by the quantity of mail on this list; is there a digestified version?) and would like to propose that I package up Inform, Frotz, and some of the associated games. Some background: In the '80s, Infocom produced a lot of excellent adventure games, and they published them all in portable, completely architecture-independant 'story files'. When you bought the game, you got an interpreter and a story file, (although you normally didn't know that). Since then, various people have decyphered the story file format and produced a compiler (Inform) to generate these files, and interpreters (Frotz being one) to play them. If we had Frotz, it would be simple to package up a large(ish) number of the games available. I suspect a lot of the games would have to go in contrib, as they don't have their Inform source with them, and Inform itself would have to be non-free, 'cause it has restrictions on profit-making. I think Frotz could go in the main distribution, but I'll have to check on that... Oops, no: Frotz is freeware: It may be used and distributed freely provided no commercial profit is involved. (c) 1995, 1996 Stefan Jokisch. So, is anyone else working on any of this already? Good/bad idea? How should I go about approaching the authors to ask them to change the licences for these programs (if I should, if fact, do that)? Thanks, --Charles Briscoe-Smith PGP key fingerprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 White pages entry, including PGP key: URL:http://alethea.ukc.ac.uk/wp?95cpb4 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
= Communication should be done via a package-specific mailing list. The = maintainer of the package decides who has commit privileges for this = package and who gets on this package's developers' mailing-list. = = The way we are currently doing it here (at Pixar) is that nobody checks = in an un-reviewed patch, even if they do have commit privilege. Anyone = with commit privilege can review it for you and give you an OK to check = it in, but it takes two people. It tends to make us think a bit harder = about what we are doing. There are advantages to commiting intermediate versions and un-reviewed patches. The redundancy is a good idea - you won't lose all your work if the disk crashes or somebody does 'rm -r /'. But perhaps a bigger advantage is anyone anywhere with CVS access can use 'cvs diff -rSTABLE' to review the changes -- they don't have to depend on you preparing a 'diff' e-mail or something. They can even check out the trial version to build or test or even compare your changes to their changes. The final commit is done by moving a tag or potentially moving something to a stable branch. This can be on the honor system since CVS doesn't have per-tag access control (that I know of) with audit possible (I think) through the CVS log files. Obviously all official/stable release/builds occur from the STABLE tag. -P -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Christian Hudon wrote: --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii On May 24, Tom Lees wrote The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And it changes the conffiles, which means that the user will still get bugged with Conffile changed, overwrite with package's version or keeps yours? questions from dpkg, which is exactly what we want to avoid with cfgtool. There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. So, for example:- #!/bin/sh # the blah script some code BLAH=yes# config=yes If this becomes:- #!/bin/sh # the blah script some code BLAH=no # config=yes It still gets excluded from the md5sum, but if someone changes it, like:- #!/bin/sh # the blah script some code BLAH=no Then dpkg gets a different md5sum, and prompts, because it is included this time. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Man-Db and Man both in Frozen???
John Goerzen wrote: Hi, There appears to be a package man in frozen that shouldn't be there since man-db is the new name for that package. Somebody needs to take it out; otherwise, it is confusing to users. John Where is it? I've just looked both in ftp.debian.org and in master, but man_ is only in rexx . Or maybe it has been just removed? Fabrizio -- +--+ | [EMAIL PROTECTED] [EMAIL PROTECTED] - Using Debian GNU/Linux ! | | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | La Liberta' non e' uno spazio libero, Liberta' e' partecipazione.[gg]| +--+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Christian Schwarz wrote: Next step: GNU's configure utility. I thought that we had agreed on using i386-unknown-linux (and similar for the other architectures), but then I had just discovered that GCC uses /usr/lib/gcc-lib/i486-linux/2.7.2.1/ ^^ (first it says i486 instead of i386, second it ommits the unknown). Yes, for hysterical raisins, we use i486 instead of i386. The difference is reflected in the results you get form dpkg --print-architecture and dpkg --print-gnu-build-architecture. On most systems, these are identical. On Intel, they happen to be different. We leave out the unknown becuase A) it's ugly, and B) nobody cares who built your silly pc-clone box anyway. They're all the same, except for the ways in which they are different. :) (Don't ask me what the historical reasons are, though. I might start to whimper...) --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
