Re: first package
but the second error seems to be more serious. in line 1 of my changelogfile is nothing wrong compared to the script. it just says: z (1.0-1) unstable; urgency=low (my package is called 'z' for now) is the name a problem (too short)? renamed it to zet: that works. so debian package names are more than one chars long? seams to be a bug in build? (whatever sense it makes to have that short names) -- see header -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf not losing info.
On Tue, 2 Jun 1998, Shaya Potter wrote: Sorry for not responding directly, I only get debian-devel-digest, so I can only respond to what I catch. I believe linuxconf will version every change that it makes, i.e. if you make changes w/ linuxconf and see that it didn't work, you can go back to your previous configuration or any one of many previous configurations, this will probably work if you edited it outside of linuxconf, you then edited the file manually, and then went into linuxconf, somehow or another linuxconf messed up the file (though when I was playing with it last year, it couldn't grok our dns setup, and just complained, didn't mess with it), you should theoreticly be able to go back to the version you modified by hand, because linuxconf should have saved it before modifying the file. good. i like the sound of that. does it use RCS or similar to store the previous versions? if not, how hard would it be to make it do so? craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: another look at release-critical bugs: lpr
On Sat, 30 May 1998, Jay Wardle wrote: [...Raul wrote...] If this can't be fixed easily, perhaps we ought to promote lprng to standard and demote lpr to optional. Yes, I know that bug-for-bug compatability is a nice thing, but in my experience lprng is superior to lpr. -- Raul In my (admittedly limited) experience, lpr is superior to lprng. Both a friend and I could not get lprng setup on our systems. It requires a lot of configuration work. We had both spent a significant amount of time with lprng, and lpr was a snap. we have the exact opposite experience then. i found lprng to be a breeze - the package basically configures itself, especially if you also install magicfilter. I don't use lpr on any system any more. if i find anyone on my network has installed lpr (i have several debian users at work now...converting them was easy, once they realised it was convert or perishmwahahahaha!) then i remove it and replace it with lpr. lpr is clearly the best choice for most of the small system users. i disagree. i find that the integration between lprng and magicfilter makes it the best choice for anyone who just wants something that works out of the box lprng, magicfilter, gs (or gs-aladdin), and enscript : THE printing suite for linux systems. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Gosh!!! This really was good Manoj. I really enjoyed reading this technical dissertation on the magic of Debian. Can't this be placed somewhere in www.debian.org? E.- Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, Well, there are a number of things, but the following are important (in no particular order) -- Eloy A. Paris Information Technology Department Rockwell Automation Venezuela Telephone: +58-2-9432311 Fax: +58-2-9431645 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf
On Tue, 2 Jun 1998, Joel Klecker wrote: At 07:40 -0700 1998-06-02, Craig Sanders wrote: BTW, the fact that you don't understand sendmail doesn't prevent others from doing so. sendmail really isn't that difficult, and is simpler in some ways because you don't have multiple config files scattered across multiple directories. FUD, exim also uses only one configuration file. I'm sure I could understand sendmail if necessary, but I have the luxury of not needing to, and since I don't want to, I don't have to. i may be confusing exim's config with smail. when i (very briefly) looked at it last year, it seemed to be smail done right. i don't like smail (even when it is done right) so gave up on it after a few days. i also looked at zmailer. now that definitely has zillions of config files scattered over zillions of directories. ok, zillions is a slight exaggeration, but not by much :-). looked to have some nice ideas, but not my cup of tea. qmail was the only alternative mailer i looked at that i actually liked. It's the only one i would even consider as a replacement for sendmail. I'd be running it now except for two things: 1. the license, 2. the Qmail Attitude Problem (QAP). Actually, there are two QAPs. The first is the unbearable and unjustifiable defensive arrogance on the part of the author and certain over-zealous users. The second is the attitude that your legacy systems are a crock of shit, throw it all out and do it the tada!Qmail Way/tada!e.g. getting majordomo to work with it is a major pain in the arse - and the fact that ezmlm exists is irrelevant if i've got 83 users with 83 different majordomo lists which they have been running for years. Right now, all but one of my systems is running sendmail. I have one box running qmail (being used as an outbound relay...my main sendmail box at works relays all non-local mail via the qmail box to take advantage of qmail's faster queueing and delivery). i'm waiting for vmail to come out of vapourwarethen i'll check that out too. it *sounds* good. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
problem with dselect and the dists hierarchy
abstract: there might be a serious problem involving dselect and hamm's new distribution format that threatens to make Debian 2.0 cd's unusable. Hi, I've been doing some tests lately with a harddisk with a full mirror of hamm-i386. Apart from keeping my main home machine up to date with it, I have also tried some of the various access methods that dselect provides with it. With the ftp method I have found no problems. With the various disk methods, there are problems however. These problems are such that, if they are not fixed before hamm is declared stable and subsequently pressed onto millions (oh well) of silver cd's, these cd's will be pretty much worthless to most people that buy these cd's. The problem appears to be present all of the in the cdrom, nfs, harddisk and mounted access methods that all make use of the same setup script /usr/lib/dpkg/methods/disk/setup . The script has stable/binary hardcoded all over. There's are probably also a couple of /tmp races in it. At first, I've tried to kludge around the problem by creating a stable symlink in the /debian distribution root, but that doesn't really solve the problem, as the format of the distribution tree has changed in more than one place. I found that when I fill in bogus information when setting up any of the disk methods in dselect and then editing the contents of /var/lib/dpkg/methods/disk/shvar.* manually will make dselect's update and install methods work if the edits are done right. It works, but this is not something that should reasonably be expected from new users just wanting to install Debian from cd. A workaround is still possible, using a couple of smart symlinks, but there are a couple of reasons why it is better to look into the real problem: - the options for multiple binary cd's will probably have to be considered anyway. I don't think that dselect in it's current form is capable of handling that; - the script uses /tmp files, quite possibly in an unsecure manner; - it would be nice if some form of autodetection were added to the setup script. We all agree that a lot of new users are confused when faced with questions like what is your block device? Currently, this is the way dselect's interacts with the user; - /usr/lib/dpkg/methods/disk/setup is a shell script with snippets of perl code incuded. IMHO it is not a bad idea to write the whole script in perl, considering that it assumes perl to be present anyway. Cheers, Joost -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
Santiago Does this mean the modified-for-Debian mirror may not be Santiago distributed inside the .deb binary package? Well, in mirror_2.9-1, all files by Lee are unmodified. No patches yet ... Marcelo Isn't that distributing modified bynaries? I mean, you are not Marcelo distributing the .orig.tar.gz, but something different (with added Marcelo parts, and incidentally, one of them is the original thing) No added parts yet, but we are in fact under a restriction not to ever change it. Not that nice, really. The weird thing is that he mentions Debian a couple of times in the Changelog. Marcelo I got an announcement from Freshmeat that said GNU Mirror, I know. I wrote to them pointed out that it's not GPL, and got a reply that they changed it. -- mailto:[EMAIL PROTECTED] According to the latest official figures, http://rosebud.ml.org/~edd 43% of all statistics are totally worthless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with dselect and the dists hierarchy
Hi, When Hamm is released, then Hamm shall be stable. Having stable hard coded is not such a horrendously bad idea (not great, but not as disastrous as may seem). Personally, I have stopped using all the dselect methods in favour of the apt method for dselect. However, I understand that apt is likely to be too perfectionist for general consumption yet. manoj -- Buy land. They've stopped making it. Mark Twain Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
Bob I would like to see this feature continued if it isn't in 2.9-1 Bob by default. Note that the license currently states that distributing modified versions of mirror is not koscher. There were way more patches, big and small. Maybe I should release a mirror28 package which preserves these ? -- mailto:[EMAIL PROTECTED] According to the latest official figures, http://rosebud.ml.org/~edd 43% of all statistics are totally worthless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On Tue, Jun 02, 1998 at 12:35:35AM -0500, Manoj Srivastava wrote: David Reread some of my earlier messages. I firmly believe that a David lack of strong leadership has been one of the biggest David contributing factors in Debian's inability to put out timely David releases. I think that placing the blame on the leadership is a) non productive, and b) the easy way to duck blame. My choice of wording was poor. My intent was not to place blame. Everyone, myself included, was to blame for letting things drift off course in the past. Rather, my point is that strong leadership is needed to help keep everyone focused and the project on course in the future. The Debian project is too big for one person. We need now a formalized method for initiating changes; and that we are getting, once we ratify the constitution. [...] You are talking about the growing pains of a project that has gone beyond the old boys club, and can no longer operate in an ad hoc fashion. I guess we're just going to have to disagree. I've stated before that a democracy is not the best way to run Debian and I still stand by that. Democracy is the right way to run a government. It is not the right way to run a project. I would much rather see a single person or small group of people, with the right vision and skills, be put in charge (with some checks and balances, of course) and let them manage. In my opinion, this is thinking in the mold of the old ways, when a godly central project leader made or broke the project. Read teh constitution. We need to go beyond the dependency on one individual. We have the talent to discover a process, a business model, so to say, that enables us to put forth releases on a more frequent time table. I have read the constitution. It is way overkill and places too much potentially destructive power in the hands of developers. Voting by developers should be limited to the election and recall of leaders and the ratification of amendments. Developers should still be allowed to make proposals but the final decision making authority should rest with the leaders or their delegates. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Hi, What is the benefit of keeping packages in an unconfigured state? This shall certainly play havoc with large scale upgrades, when latter packages require earlier packages to be configured. To be absolutely certain, you may, in the worst case, have to set up and configure packages one at a time. Why is the prospect of asking the questions a priori or an interactive configuraion supposedly so vastly inferior? Has anyone actually tried upgrading severl hundred packages at a time? Has anyone considered the effect on dependent packages? I would like to see a bunch of status files, and an apt -s upgrtade run, and a study of what happens to the install when packages are left unconfigured. manoj -- I am convinced that the manufacturers of carpet odor removing powder have included encapsulated time released cat urine in their products. This technology must be what prevented its distribution during my mom's reign. My carpet smells like piss, and I don't have a cat. Better go by some more. [EMAIL PROTECTED], in alt.conspiracy Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with dselect and the dists hierarchy
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Umm. I don't know how to say this tactfully. I shall Manoj try. It may be better, I think, in this and other tasks Manoj (like modifying dpkg), that the new author be one able to Manoj grok the original. *grin* No, I'm not offended. :) Manoj Shell scripts should generally be mechanically Manoj transformable to Perl, and I have had a look at this one, Manoj though not trivial, it is certainly eminently doable. The Manoj question is, should we be doing it at this late stage in Manoj the game? I think it's critical that we at least remove the horrid prompts asking you your block device for your CD-ROM, or at least make an intelligent guess and provide a default. Manoj By the next release we shall hopefullybe using apt, or Manoj at least the apt-get method under dselect, when all this Manoj shall be moot. Will apt be able to deal with multiple cd-roms? I hope so! -- Brought to you by the letters F and J and the number 18. I'm calling from the plane. I'll call you when I get there. -- TMBG Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: first package
On Wed, Jun 03, 1998 at 02:18:03AM +0200, Michael Dietrich wrote: but the second error seems to be more serious. in line 1 of my changelogfile is nothing wrong compared to the script. it just says: z (1.0-1) unstable; urgency=low (my package is called 'z' for now) is the name a problem (too short)? renamed it to zet: that works. so debian package names are more than one chars long? seams to be a bug in build? (whatever sense it makes to have that short names) I think you also can't use a numeric as the first letter of a package. I remember having problem with this when i packaged 8hz-mp3. I don't remember if it was debhelper or build that i had problem with. Nevertheless, a package with only one letter is not very descriptive even if it follow policy. ie. Package names may only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.). -- Eric Leblanc -- [EMAIL PROTECTED] -- Be happy use GNU/Linux As for the M$ pundits claim that the problems result from an incorrect setup/configuration: they are perfectly correct, if you hadn't installed an M$ OS, then the crashes wouldn't be happening. -- Jeff Dutky on c.o.l.a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Manoj hit all the major points, and about every other point under the sun :) But I would like to expand on what I think are the key differences. 1) It's a distributed volunteer based system with lots of contributors. This sometimes leads to long arguments, but it means that policies must be thrashed out and specified precisely. It means that systems must have well designed modular interfaces to make it possible for packages to be maintained effectively by different maintainers. It also means we have a huge number of packages, all of which are held to the same standards and using the same bugtracking system. No directories of use at your own risk contributions. 2) Debian has a very strong commitment to Free Software. Everything in the distribution proper is supposed to be Free Software. Non-free software is in a separate section which isn't included on most CDs. Users of Debian can be sure they have the freedom to use and modify any component of the distribution without breaking restrictive licenses. I've included our Social Contract and the Debian Free Software Guidelines below to help make this clearer. Debian GNU/Linux Social Contract We are Software In The Public Interest, producers of the Debian GNU/Linux system. This is the social contract we offer to the free software community. Social Contract with the Free Software Community 1. Debian Will Remain 100% Free Software We promise to keep the Debian GNU/Linux Distribution entirely free software. As there are many definitions of free software, we include the guidelines we use to determine if software is free below. We will support our users who develop and run non-free software on Debian, but we will never make the system depend on an item of non-free software. 2. We Will Give Back to the Free Software Community When we write new components of the Debian system, we will license them as free software. We will make the best system we can, so that free software will be widely distributed and used. We will feed back bug-fixes, improvements, user requests, etc. to the upstream authors of software included in our system. 3. We Won't Hide Problems We will keep our entire bug-report database open for public view at all times. Reports that users file on-line will immediately become visible to others. 4. Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environment. We won't object to commercial software that is intended to run on Debian systems, and we'll allow others to create value-added distributions containing both Debian and commercial software, without any fee from us. To support these goals, we will provide an integrated system of high-quality, 100% free software, with no legal restrictions that would prevent these kinds of use. 5. Programs That Don't Meet Our Free-Software Standards We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our FTP archive for this software. The software in these directories is not part of the Debian system, although it has been configured for use with Debian. We encourage CD manufacturers to read the licenses of software packages in these directories and determine if they can distribute that software on their CDs. Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. The Debian Free Software Guidelines 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only if the license allows the distribution of patch files with the source code for the purpose of modifying the
Re: problem with dselect and the dists hierarchy
On 2 Jun 1998, Manoj Srivastava wrote: Shell scripts should generally be mechanically transformable to Perl, and I have had a look at this one, though not trivial, it is certainly eminently doable. The question is, should we be doing it at this late stage in the game? Well, if it is broken and a user will need it, yes (when I looked at the first message, this appeared to be the case). As to how to fix it, I'll leave that to someone else's decision, but I'd suggest the method that is least likely to break and cause further problems (i.e. a complete rewrite may result in bugs that don't show up until after release, but we may be able to change it with a simple search and replace of the offending directory names). Comments? Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 596-5550 --Linus Torvalds Debian Testing Group status: http://bhmit1.home.ml.org/deb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
Hi, David == David Engel [EMAIL PROTECTED] writes: David Rather, my point is that strong leadership is needed to help David keep everyone focused and the project on course in the future. And I think if we need such leadership, we may as well pack our bags and go home, for it is not going to fly. Charismatic leadership happens. It can not be decreed, or coaxed out of nothingness. So, either we sit around waiting for charismatic leadership to happen to us and lift us out of our doldrums, or we take our destiny into our own hands and do something about it. David I guess we're just going to have to disagree. I've stated before that David a democracy is not the best way to run Debian and I still stand by David that. Democracy is the right way to run a government. It is not the David right way to run a project. I would much rather see a single person David or small group of people, with the right vision and skills, be put in David charge (with some checks and balances, of course) and let them manage. We already tried this method. Our erstwhile leader was charismatic, had a vision, had leadership qualities. He was boldly leading us where we had never gone before. He had us all licked into focus. He was providing leadership. And the experiment (pardon me) failed miserably. You know why? Cause the developer did not want to go where he was leading us. Debian is not a nation. It is not a company. You can't have one person crack a whip and keep the galley slaves in line. Benevolent dictatorships have a tendency to grow corrupt. And fail. Leader ship by the Elite. Isn't that what the asian markets were all about? No open process, no protocols, just old boy networks of elites? 'Tis a new world order, my friend. David I have read the constitution. It is way overkill and places too much David potentially destructive power in the hands of developers. Since the developers do all the hard work, (and believe me, sleep deprivation is not a jke, and many suffer from it), we are not likely to be ``destructive''. And if we did collectively wish to be self destructive, who has the right to stop us? David Voting by developers should be limited to the election and David recall of leaders and the ratification of amendments. Why? Because even though we do all the work, the masses are too dumb to do their own masters? We need a all knowing, all powerful group of people to tell us how to act? What cventury are we in now? David Developers should still be allowed to make proposals but the David final decision making authority should rest with the leaders David or their delegates. I refuse to let any opne have such power. Unless they pay me. Shall I make my rates know to the supposed leaders and delegates? What makes leaders and delegates so special that they can command the masses that do the work? When they bleed, does their blood run blue? manoj admittedly incensed -- Lord FINCHLEY tried to mend the Electric Light Himself. It struck him dead: And serve him right! It is the business of the wealthy man To give employment to the artisan. Belloc Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with dselect and the dists hierarchy
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hi, When Hamm is released, then Hamm shall be stable. Having Manoj stable hard coded is not such a horrendously bad idea (not Manoj great, but not as disastrous as may seem). Actually its a problem not because stable is hardcoded, but because the directory structure of a year ago is. Notice it looked for debian/dists/stable/binary-i386, which does and will not exist. The real directory is debian/dists/stable/main/binary-i386, if anything. - PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C __ _Debian GNU Johnie Ingram [EMAIL PROTECTED] mm mm / /(_)_ __ _ ___ __netgod irc.debian.org mm mm / / | | '_ \| | | \ \/ / m m m / /__| | | | | |_| |Yes, I'm Linus, and I am your God. mm mm \/_|_| |_|\__,_/_/\_\ -- Linus, keynote address, Expo 98 GO BLUE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
Dirk == Dirk Eddelbuettel [EMAIL PROTECTED] writes: Dirk Note that the license currently states that distributing Dirk modified versions of mirror is not koscher. I fretted at first, then noticed what it prohibited was distributing modified code, not modified binaries as pine demands. This may just be an unclear attempt to prevent people from passing off hacked code as the unmodified mirror program, something Debian, with its .diff.gz, doesn't do. But it still needs to be possible for people to modify the program after renaming it, as the Artistic license allows. Hmm - PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C __ _Debian GNU Johnie Ingram [EMAIL PROTECTED] mm mm / /(_)_ __ _ ___ __netgod irc.debian.org mm mm / / | | '_ \| | | \ \/ / m m m / /__| | | | | |_| |Yes, I'm Linus, and I am your God. mm mm \/_|_| |_|\__,_/_/\_\ -- Linus, keynote address, Expo 98 GO BLUE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with dselect and the dists hierarchy
Hi, Johnie == Johnie Ingram [EMAIL PROTECTED] writes: Johnie Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hi, When Hamm is released, then Hamm shall be stable. Having Manoj stable hard coded is not such a horrendously bad idea (not Manoj great, but not as disastrous as may seem). Johnie Actually its a problem not because stable is hardcoded, but Johnie because the directory structure of a year ago is. Johnie Notice it looked for debian/dists/stable/binary-i386, which Johnie does and will not exist. The real directory is Johnie debian/dists/stable/main/binary-i386, if anything. Oh, I see. Well, that is even easier to fix ;-) A simple search and replace should work, I think, from a perusal of the script. manoj -- Wish not to seem, but to be, the best. Aeschylus Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Hi, A short while ago, Ian proposed a specification for an Automatic query servicing for dpkg installation scripts. I thought that the spec was very well thought out, and really, the best bet for Debian were we to put in serious work on the project. (Unfortunately, some of the proposals flying around recently are best labeled, charitably, half baked). I shall refresh the collective memory (which is, stereotypically, short ;-) manoj From: Ian Jackson [EMAIL PROTECTED] To: debian-devel@lists.debian.org, debian-policy@lists.debian.org Subject: Re: Proposal: Automatic query servicing for dpkg installation scripts Date: Tue, 19 May 1998 13:35:41 +0100 Yes, we do need something like this. Properties that it needs to have include, in no particular order: 1. Questions may need to be `independent' of any particular package. 2. Only a particular package can determine which questions need to be asked in what order; in particular, following questions can depend on the previous ones. This means that we can't specify the questions in advance in a file. Instead, we have to put the information in command-line arguments to the query program. 3. Questions should have a `name' that is textual (not numeric), and is separate from the prompt string. Given 1. the name should probably have a hierarchical structure. Given 2. there needs to be a way to put arbitrary `parameters' into the `name'. 4. There should be a way to specify how `important' it is that a question be asked, and an environment variable or something to specify how willing we are to prompt, so that we can tune the level of prompting. 5. The interface should be suitable for changing the UI later (eg, plain-text, fullscreen text, X or whatever). 6. The database format used to cache answers should be editable by humans. 7. The query program should be the same as the retrieve-question program, so that the database of previous questions acts as a cache for the user. 8. If the query program cannot prompt but the arguments say it needs to then it should indicate this with a nonzero exit status, which will (hopefully) cause the script to bomb out. 9. Valid responses should be specified by regexp (preferably a reasonably fully-featured regexp like a Perl one) not a glob. 10. Metacharacters in prompts and data should work completely correctly. Ian. -- Besides, it's good to force C programmers to use the toolbox occasionally. :-) --Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: What is the benefit of keeping packages in an unconfigured state? It's a reminder to me that I need to configure this package still. This shall certainly play havoc with large scale upgrades, when latter packages require earlier packages to be configured. No worse than the current situation. There aren't that many Predepends at the moment. For instance, I unpack mesa dpkg --unpack -B mesag2_2.6-4.deb Preparing to replace mesag2 2.6-3 (using mesag2_2.6-4.deb) ... Unpacking replacement mesag2 ... dpkg --audit mesag2 A 3-D graphics library which uses the OpenGL API [libc6]. dpkg --status xlockmore-gl Status: install ok installed Depends: libc6, mesag2 (= 2.6), xlib6g (= 3.3-5), xpm4g (= 3.4j-0) xlockmore-gl didn't deconfigure. It still works. Now perhaps xlockmore-gl *should* be marked as unconfigured, but it currently isn't. If mesag2 asked a question (it doesn't) and were killed, it could still meet other package's dependency requirements (the library is present to link against). mesag2 just can't meet a Predependency. Why is the prospect of asking the questions a priori or an interactive configuraion supposedly so vastly inferior? It's mostly a question of when they get asked. At the moment, all packages are configured at once. During a major upgrade, 90% of packages configure without human intervention. The remaining 10% are scattered among them, resulting in about 90% wasted time waiting for prompts. Emacs and TeX in particular take a considerable amount of time to configure, but don't usually ask questions. Under apt, the interactive stage will be even longer, as you have the unpacking and possibly download times mixed in with the configure time. It will be an even longer wait between questions. An alternative is to configure the 90% of packages that don't ask questions immediately, and configure the remaining 10% at your convenience. And file wishlist items against the informational pauses.. Has anyone actually tried upgrading severl hundred packages at a time? Yes, last night. I'd have gone home an hour earlier if I could have left the questioning packages in an unconfigured state. run, and a study of what happens to the install when packages are left unconfigured. This happens to me frequently under dselect. I'll start a machine upgrading and leave for a while, get busy, and not check the window for a day. Most times the user (or me) doesn't even know their system is halfway through an upgrade with 90 packages left unconfigured, because they've all unpacked and the first one is asking a question. I'd like the option of ignoring that question until later and having the rest configure themselves. For a compute farm, I'd definitely prefer to eliminate as many questions as possible, but when a question does arise, I'm probably doing a non-interactive install anyway (in an iconified window or something), and would rather it continue with easier packages and ask me again later. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tools the Parse config files (was Re: Linuxconf)
At 12:46 PM 6/2/98 -0500, Manoj Srivastava wrote: Hi, Shaya == Shaya Potter [EMAIL PROTECTED] writes: Shaya Also, linuxconf shouldn't be used to configure a user's Shaya personal information, such as .bashrc, .pinerc, those should Shaya be left to either the program itself like in pine, or to a Shaya package like the dotfile generator for a program like bash or Shaya procmail. Why not use linuxconf? I am not contradicting you, just asking for clarification. I don't feel Linuxconf is suited for that. It's just my gut feeling, it could probably be extended to do it, but it seems to me like it would be good if there was a seperation b/w the program the configures the system, and the program that configures the user. Not technicall reasons, just looks. Shaya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files
On Tue, Jun 02, 1998 at 11:55:06AM -0500, Manoj Srivastava wrote: Hi, Charles == Charles Briscoe-Smith [EMAIL PROTECTED] writes: Charles Manoj Srivastava writes: Charles $ gzip -l Sizes.hamm.*.gz Charles compressed uncompr. ratio uncompressed_name Charles 105201795450 86.7% Sizes.hamm.contrib Charles 66294402982 83.5% Sizes.hamm.main Charles 11446 63766 82.0% Sizes.hamm.non-free Charles 182941 1262198 85.5% (totals) Charles Looks reasonable... In practice, this information is only Charles going to be used while installing packages, and 180K isn't Charles much anyway. We could save far more space by compressing Charles the available, available-old, status and status-old files Charles (2.5Mb on my system). Manoj We have conflicting data here. Mrvn says that the total du Manoj data is only 76k. Charles says that the data is about 400k Manoj (which is way more in line with my off the cuff calculations). Charles The 400K was for normal hamm Packages files with additional Charles Du data added to it. That makes my numbers far closer to Charles Mrvn's. Also, weren't Mrvn's figures were for main only? I stand corrected. Seems like my off the cuff estimates were off a bit. Manoj I also would strongly advocate *NOT* stuffing this data into Manoj the Packages or the Available files, but keeping this apart on the Manoj archive and when downloaded on the users disk. Charles I'm now with you on this one. Given the sizes involved, I Charles don't think we even need to go to the trouble of generating Charles the top N levels versions. Using this would make it Charles difficult to take symlinks into account. Well, now all we have to do is decide how this information should be gathered. Does the package maintainer stick it into the deb file? Should one upload the file separately (possibly modifying dpkg-genchanges to also pgp stamp the sizes file, though I think a hacked sizes file is not a major security breach, as long as the package itself is intact). If we go with a separate file kernel-package_4.08-1_i386.sizes.gz; then all we need is a modified dupload, and a modification of Guys script to handle the sizes file, even stashing it some place on the archive (debian/dists/unstable/sizes-i386/misc/kernel-package_4.08-1.gz) though that location maybe suboptimal cause of the mirrors. dinsall can just zcat the files sa needed. Comments? I think the right place is in the *.deb-file. In the control-file (like the description) or as new file in *.deb. So we must modified buildpackage. But I thinkt also, that we should change Guys script. It should make a Package-size[.gz] file (like Packages[.gz] on the ftp-server) from old and new packages. Dselect or apt can download it and calulate the packagesize without download the deb-packages. Comments? Grisu pgpSKCzGgZjVl.pgp Description: PGP signature
Re: Differences of Debian vs. the Other Guys
On 02-Jun-1998, Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] wrote: I'm currently writting an article for Linux Actual (an spanish magazine on Linux) about the Debian Packaging System (more on the .deb format than other policies) and I would like to make the BIG question, considering there is a lot of discussion about LSB. start big question --- What are the main differences/advantages/disadvantages of Debian's Packaging System vs The Other Guys (tm) ? --- end big question --- Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. rpm encourages (practically enforces) building a package, installing it in /usr, then listing all the files that were just installed. e.g.configure --prefix /usr make make install package up all listed files This is very error prone. Three big problems can occur: 1. Maintainer lists files that were on their system, but were not generated by the source archive. This means that the source RPM cannot generate the binary RPM on anyone elses system (except perhaps if they install the binary first, then create the package -- but it's a risk, and might eventually lead to packages that cannot be effectively maintained). 2. Maintainer fails to list files that were installed. Package works fine for them, because they installed the files using make install, so all files are present. Package doesn't work for anyone else. 3. Package maintainers machines get full of junk files, because they are only *producing* packages for people, their own system is used to install packages. When I discovered this is how rpm works, I was very disappointed. dpkg has gone the extra mile, and done things properly, despite being a bit more difficult to implement. dpkg makes packaging quicker, cleaner, and less error-prone. Add to this the lovely cvs-buildpackage (automatically builds packages out of CVS archives), and dpkg is a formidable packaging system. .deb vs .rpm isn't much competition -- they are both functionally equivalent at this level (so are .tar.gz or a .zip files really). But when you look at the tools and process used to create a .deb versus a .rpm, I think RPM needs some work. But chances are there are things I don't know about RPM -- I looked at it a while ago. Good luck on your article. -- Tyson Dowd # So I asked Sarah: what's the serial number on # your computer? She replied: [EMAIL PROTECTED]# A-C-2-4-0-V-/-5-0-H-Z http://www.cs.mu.oz.au/~trd # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Hi, Drake == Drake Diedrich [EMAIL PROTECTED] writes: Drake On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: What is the benefit of keeping packages in an unconfigured state? DrakeIt's a reminder to me that I need to configure this package still. I prefer the approach to ask questions first, and configure as it installs. If we are spending time to do this, we should do this right. This shall certainly play havoc with large scale upgrades, when latter packages require earlier packages to be configured. Drake No worse than the current situation. There aren't that many Drake Predepends at the moment. For instance, I unpack mesa [anecdotal script of a deconfigured package still working deleted] Yes, it is. I prefer not to have sendmail,. bind, and NFS be deconfigured and non working until I configure them (after hours of download and install) There are no guarantees that an unconfigured package shall not prevent dependent packages from configuring or working right. Why is the prospect of asking the questions a priori or an interactive configuraion supposedly so vastly inferior? DrakeIt's mostly a question of when they get asked. At the moment, all Drake packages are configured at once. During a major upgrade, 90% Drake of packages configure without human intervention. The Drake remaining 10% are scattered among them, resulting in about 90% Drake wasted time waiting for prompts. Emacs and TeX in particular Drake take a considerable amount of time to configure, but don't Drake usually ask questions. Then this is what we fix. We don't make half baked attempts to do non interactive installs. We fix the correct problem, namely, do not ask questions in the middle of the installation. Drake Yes, last night. I'd have gone home an hour earlier if I Drake could have left the questioning packages in an unconfigured Drake state. Maybe you have the luxury of having a box be unconfigured and non working when you go home. A lot of us are not so lucky. We prefer answering the questions first, and then starting the upgrade. barring bugs, the machine down time is minimized. Drake For a compute farm, I'd definitely prefer to eliminate as many Drake questions as possible, but when a question does arise, I'm Drake probably doing a non-interactive install anyway (in an Drake iconified window or something), and would rather it continue Drake with easier packages and ask me again later. For a compute farm, I would prefer answering the questions ONCE, and then replicate the config database. As I said, let us solve the real issues, not apply band aids. manoj -- The notion that science does not concern itself with first causes -- that it leaves the field to theology or metaphysics, and confines itself to mere effects -- this notion has no support in the plain facts. If it could, science would explain the origin of life on earth at once--and there is every reason to believe that it will do so on some not too remote tomorrow. To argue that gaps in knowledge which will confront the seeker must be filled, not by patient inquiry, but by intuition or revelation, is simply to give ignorance a gratuitous and preposterous dignity Mencken, 1930 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
At 23:38 -0700 1998-06-02, Tyson Dowd wrote: Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. Another one is that he didn't explain what dpkg-shlibdeps does. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. That isn't the right way to do it, the executables may end up depending on being run from the same directory as the one they were built with (in practice, it doesn't seem that too many packages are like that, but it's good to keep it in mind). The correct way to do it (for most GNU autoconfized packages) is: ./configure --prefix=/usr make make install prefix=`pwd`/debian/tmp/usr In some cases this may cause a rebuild with the new path configured in, in which case it is necessary to do a bit more work in the rules. (The documentation for GNU stow is useful for a few strategies in dealing with such cases). -- Joel Espy Klecker Debian GNU/Linux Developer mailto:[EMAIL PROTECTED] http://web.espy.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tools the Parse config files (was Re: Linuxconf)
On Wed, Jun 03, 1998 at 07:43:22AM +0300, Shaya Potter wrote: Shaya Also, linuxconf shouldn't be used to configure a user's Shaya personal information, such as .bashrc, .pinerc, those should Shaya be left to either the program itself like in pine, or to a Shaya package like the dotfile generator for a program like bash or Shaya procmail. Why not use linuxconf? I am not contradicting you, just asking for clarification. I don't feel Linuxconf is suited for that. It's just my gut feeling, it could probably be extended to do it, but it seems to me like it would be good if there was a seperation b/w the program the configures the system, and the program that configures the user. Not technicall reasons, just looks. This doesn't mean that user config can't be done with the same kinda interface. liblinuxconf, anyone? pgpR29FrDyoCP.pgp Description: PGP signature
Re: On adding size info to Packages files
Hi, Michael == Michael Bramer [EMAIL PROTECTED] writes: Michael I think the right place is in the *.deb-file. In the Michael control-file (like the description) or as new file in *.deb. Why do you think so? You don't give any reasons whatsoever, so this is not a technical statement, but a mere expression of personal preference. I personally think that is a bad idea for the folowing reasons: a) the data is harder to manipulate: as a separate file, dinstall just has to rename the file to a cache area, and use zcat and echo to generate the master sizes.gz file. As a control file, dinstall has to unpack the .deb file and extract the data. b) The data is only needed on *some* machines, and only at install time. As a separate file, it can be downloaded as needed, or not at all (I have no need to slow down my installs, I know I have plenty of space at the moment). When it is part of the .deb file, the data is carried around with the package all the time, whether needed or not. This is needless duplication and wastes network bnadwidth too. c) a control file is unpacked and kept in /var/lib/dpkg/info area, which is a waste of space. The data is needed *before installation*, not afterwards. From the KISS principle, a separate file makes more sense than embedding the data in the .deb file, (making it harder to access it). Also, a separate file can initially be tested without changing *any* dpkg tool (Guy just modifies his script) manoj -- For I lean on no dead kin, my name in mine for fame or scorn And the world began when I was born and the world is mine to win. Badger Clark Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files
On Wed, Jun 03, 1998 at 02:25:39AM -0500, Manoj Srivastava wrote: Hi, Michael == Michael Bramer [EMAIL PROTECTED] writes: Michael I think the right place is in the *.deb-file. In the Michael control-file (like the description) or as new file in *.deb. Why do you think so? You don't give any reasons whatsoever, so this is not a technical statement, but a mere expression of personal preference. Oh yes, I see .. I personally think that is a bad idea for the folowing reasons: a) the data is harder to manipulate: as a separate file, dinstall just has to rename the file to a cache area, and use zcat and echo to generate the master sizes.gz file. As a control file, dinstall has to unpack the .deb file and extract the data. I think this not a point. dinstall get the size.gz file from the .deb file (ar -x) and put it to the cache area. I don't see the difference? (And for old .deb files: dinstall unpack the .deb file in /tmp/../ and make the size.gz-file) b) The data is only needed on *some* machines, and only at install time. As a separate file, it can be downloaded as needed, or not at all (I have no need to slow down my installs, I know I have plenty of space at the moment). You use .deb file only at install time. After that you will remove all *.deb from your hard disk. (If you don't remove the *.deb then you have a very big disk and the kBytes are not the point..) When it is part of the .deb file, the data is carried around with the package all the time, whether needed or not. This is needless duplication and wastes network bnadwidth too. All the time. You use .deb only for the install time.? You don't? c) a control file is unpacked and kept in /var/lib/dpkg/info area, which is a waste of space. The data is needed *before installation*, not afterwards. This is a point. But I say: Michael In the control-file (like the description) or as new file in *.deb. see the 'or' Then put the du information not in the control file but put it in the .deb file. Make the du-data in a file (size.gz) and put it in the .deb file like data.tar.gz, control.tar.gz. You need the information when you install a package on your debian system. I think it is a nice to download only one file to install the package. I get often packages with ftp from a mirror and install the packages with: dpkg -i *.deb. If the the size information isn't in the debian-package, then i must download two files (NAME-VERSION.deb and NAME-VERSION.size.gz) or dpkg has no information of the size and can not make a warning message. :-( We have seperate package-functions and the interface. This is a very good. You can install package with: dpkg dselect (with use dpkg) apt (with use also dpkg) The du-information is a information like name, version, depends etc. The right place is the .deb-file. Comments? Grisu pgp09kw2dE1EB.pgp Description: PGP signature
Re: Intent to package fltk
Gregory S. Stark writes: It will still be possible to port libforms programs to libfltk probably quite easily. In many cases all that's required is making a file forms.h that includes FL/forms.H. Is it possible to compile lyx against it? I tried once but failed. This would ba a major plus to me. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I'll also be in Cologne...
Scott Hanson writes: At the last minute, I was able to make arrangements to attend the Kongress in Colonge. I'll keep my eyes open for Debian folks... Argh! And I won't. I forgot about my wife being out of town. I have to take care of the kids. :-( For the second straight time some of you guys meet close to me and I can't attend. Sh..! Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Have to get rid of at least some packages
Heiko Schlittermann writes: I'll take lshell and perforate (for perforate I'm the maintainer, as I thought for lshell too :-/ ...) Yes, I did some NMUs for it. But since you were so busy I enterer my name to lshells control file, just to get some feedback. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
-BEGIN PGP SIGNED MESSAGE- On Tue, 2 Jun 1998, Dirk Eddelbuettel wrote: Santiago Does this mean the modified-for-Debian mirror may not be Santiago distributed inside the .deb binary package? Well, in mirror_2.9-1, all files by Lee are unmodified. No patches yet ... Yes, but the point would not be whether you actually modify or not, but whether license actually allows you to do so or not, even if you do not modify it yet. Packages in main have to be DFSG-compliant, this is independent from the fact that we actually modify it for Debian or not. [ Otherwise, I could distribute my unmodified pine396-src package in main, which would be clearly against DFSG ]. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNXULBCqK7IlOjMLFAQEhtgP+O4aMdI9czapOBsodyMbgy11v91IySufT ECaJ3ZTUyIGR6XEa7XYMhSEOXsPaxy11LNIRWjMs7O/YU2Ms9iasYGE1NMht7d4X ohWJZsLdsIPiF7/KL3FCPWE/omfEmxcfckzs5gluaurtEXFberJmp14zifzeePFG PrP2ulwQXJI= =iTQQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
-BEGIN PGP SIGNED MESSAGE- Clarification, I said: [ Otherwise, I could distribute my unmodified pine396-src package in main, which would be clearly against DFSG ]. Really, this was not a good example, because pine copyright would still say No commercial use of these trademarks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNXURYSqK7IlOjMLFAQHyZQQAhAmfk1ylPOtKT/Kc4RsLUahSmxYIp9iV dXgDOsXZPQVcuZEXBESBkcwspkKNgUkbik2eGtKxLei8HjQT18Ie0ilaFgv4FzgB BnPrMKgtrhmlSH2id+TtS9nI9uPNXTrSDIVrPosdkMkLcpMpZVMfqVT03OBoAAsr jHBVw8aszHo= =rg3I -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can w3-el be precompiled?
Shaya Potter [EMAIL PROTECTED] writes: You can't. There is *no* way round this other than to upgrade gnus if you install custom. why not have custom conflict with older versions of gnus. Because gnus is embedded in emacs19, not a separate package; shurely you don't want custom to conflict with something it depends on? -- James ~Yawn And Walk North~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxconf not losing info.
On Wed, 3 Jun 1998, Shaya Potter wrote: does it use RCS or similar to store the previous versions? if not, how hard would it be to make it do so? don't know, as it's been a year since I've played with it on debian. However, that was one of the big things I requested, and from reading the linuxconf web pages, it seems he has added it, though I'm not sure how it does it. Why RCS? if it uses it's own system of just versioning the files, wouldn't that be good enough as well? if it works, then yeah it's fine. however, why re-invent a perfectly good wheel which happens to have lots of compatible utilities? e.g. various diff utils like rcsdiff and tkdiff. i prefer incremental, evolutionary growth built upon existing tools. sometimes (rarely) you have to throw out the old stuff and start afresh, but usually not. it's unfortunately very common for wheels to be re-invented simply because people don't know that they already exist or how to use them, or it never occurs to them that a tool which is well-known for one particular use (e.g. make) is also very useful for another (e.g. building and managing config files instead of compiling programs) craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to fix base-passwd
Christian Meder [EMAIL PROTECTED] writes: while testing the base packages I hit the critical bugs surrounding the update-passwd binary contained in base-passwd. Uh, which critical bugs? --sanity-check now works as expected, is run by default and update-passwd is no longer run automatically, it has to be run by the user if it is to be used. The postinst should be changed to something along the lines: update-passwd --sanity-check update-passwd -n Ask user if changes are ok. If yes update-passwd No, please don't do this. Even if you do fix all the known bugs, it's _way_ too late in the game to put an automatic call of update-passwd back in the postinst. -- James ~Yawn And Walk North~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Install size estimation (using du -S data)
Manoj Srivastava [EMAIL PROTECTED] writes: Hi, We have conflicting data here. Mrvn says that the total du data is only 76k. Charles says that the data is about 400k (which is way more in line with my off the cuff calculations). If I'm right your calculations where on the basis of the installed files. You counted one line per file. I generated a du index of all Packages, so only directories are listed. That cuts down the size by a large amount. I have not the time at the moment to run the data collection myself, but Ithink we should have this reconciled. I have personally copied everyone who seemed interested in this endeavor, and maybe we should go offline while this is resolved. Since we have a volunteer for writing a apt-size (or similar name) programm that checks the size before installing, let him do it and see how big a file he needs. I am inclined to believe the 400k figures. I would, for scalability reasons, advocate that we re run our scripts on a _ful__ i386 mirror (which I do not have at the moment -- ran out of space). My figure, as you can see from the script, was a simple du output of all Packages. I downloaded hamm/binary-i386 and hamm/binary-all before I run the script, so it should be the full i386 tree. I also would strongly advocate *NOT* stuffing this data into the Packages or the Available files, but keeping this apart on the archive and when downloaded on the users disk. The Packages are the wrong place. We couldn't tell that foo doesnt fit without downloading foo, and thats not what we want. I'm tending to have the du index in a seperate files, so one can choose to download it, or generate it from once mirror, or not use it at all. manoj May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files [very long]
Manoj Srivastava [EMAIL PROTECTED] writes: Hi, Brederlow == Brederlow [EMAIL PROTECTED] writes: Brederlow Would that already be a correct Packages file or would dpkg and Brederlow similar scream about wrong entries? Could old dpkg's handle the new Brederlow entries? As I mentioned elsewhere, there is no reason for this to be included in the Packages file. The size estimation should be *OPTIONAL*, and people should not have to download all the data unless they want the estimate. That was more a question of would and not of should. Would it be a correct Package file with something like that (or similar) in it, or would it be rejected by dpkg? Moerever, the available file (and the status file) are created from the Packages files, and there is no reason to bloat them further with duplicated information, and further increase the startup time for programs that rread them and cache them in memory. Brederlow Lets trimm those to reasonable size. Directories that are Brederlow package intern will hardly be on separate Brederlow partition. I see little reason to go through these hueristics; I prefer the original proposal of creating separate files based on the depth; however, the raw data is there for people who want it. Some Packages have a big du tree with very deep directory levels. Each directory contains only a few blocks. It should be save to assume that directories that are package intern and are less than n blocks (n small, say 100 or 50) won't be on seperate partitions. The work to do to link (or mount) those directories elsewhere is just not worth the gain (of max 100K), so it won't be done. (And if its a matter of 100K being somewhere else, the person should kick the du index all together to save another 100K). Brederlow Theres another possibility: Normal users wont backup their Brederlow System, repartition differently and restore the backup (at Brederlow least not often). Also they wont move directories around Brederlow and link them often. We could thus trimm the du tree down Brederlow to what the current system reflects. Huh? what does the current system reflect? For whose machine? Oh, you mean everytime we download the data, we spend time mucking around with it and trimming it down? I think that would be very prohibitive on slower machines, especially since the data is only useful for a short time. A better approach is to download the proper sized size file (If all my partitions are at the top level or at the second level, like /usr/lib; I just download Size.2.gz; and never do local processing on the data). I mean, that when a package is installed, that the recorded du tree (which is needed to calculate the size increase/decrease for updates) could be trimmed to what the users system reflects. The users system setup should be scanned and kept in a status file for speed reasons (trying all dirs for symlinks takes time) and then trimming should be fairly easy and save a lot of space. It would save the more the smaler (less partitions) the system is. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with dselect and the dists hierarchy
On Tue, Jun 02, 1998 at 11:42:01PM -0500, Manoj Srivastava wrote: Oh, I see. Well, that is even easier to fix ;-) A simple search and replace should work, I think, from a perusal of the script. Yes, but please may someone *do* it, and do it now! It's IMHO the only thing keeping me from recommending debian to newbies. Nils -- *-* | Quotes from the net: L Linus Torvalds, W Winfried Truemper | | Lthis is the special easter release of linux, more mundanely called 1.3.84 | | WUmh, oh. What do you mean by special easter release?. Will it quit | * Wworking today and rise on easter? * pgpZIVhUAHZPl.pgp Description: PGP signature
Re: On adding size info to Packages files [very long]
Manoj Srivastava [EMAIL PROTECTED] writes: Hi, Well, now all we have to do is decide how this information should be gathered. Does the package maintainer stick it into the deb file? Should one upload the file separately (possibly modifying dpkg-genchanges to also pgp stamp the sizes file, though I think a hacked sizes file is not a major security breach, as long as the package itself is intact). If we go with a separate file kernel-package_4.08-1_i386.sizes.gz; then all we need is a modified dupload, and a modification of Guys script to handle the sizes file, even stashing it some place on the archive (debian/dists/unstable/sizes-i386/misc/kernel-package_4.08-1.gz) though that location maybe suboptimal cause of the mirrors. dinsall can just zcat the files sa needed. The size file should be generated by the server. Here are the reasons: 1. The upload should be unpacked to check if the gz is not corrupted. (Far to often some Package is broken) 2. The du indexes should be gathered and pipe into one file to gain far better compression. 3. Maintainer will forget to include a du index or have different block sizes. The Server should hold a unpacked Version of each Package's du index and after processing all uploads it should combine and pack them. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
[ This post is a on the long side, and probably not of interest to many (sorry). It comes up with the conclusion that Debian and Democracy don't mix. ] David Voting by developers should be limited to the election and David recall of leaders and the ratification of amendments. Why? Because even though we do all the work, the masses are too dumb to do their own masters? We need a all knowing, all powerful group of people to tell us how to act? What cventury are we in now? No, because democracy is inefficient in our case. Rather than give every passenger on the bus a steering wheel, let the passengers vote for one of their number to be the driver, and let them decide which tunings to take, based on the hubbub of ``lefts'' and ``rights'' heard from the passengers. If the driver fails to keep the bus on the road, vote for a replacement. Democracy is a tool for allowing people that are under the power of an authority, to at least feel as though they have some power in the situation (even if it is only the power to exchange one despot for another) We developers are not under anyone's power, since we can always do our own thing, or leave the project, so the protection democracy gives is unnecessary and adds wasteful overhead to the decision making process. David Developers should still be allowed to make proposals but the David final decision making authority should rest with the leaders David or their delegates. I refuse to let any opne have such power. Unless they pay me. Shall I make my rates know to the supposed leaders and delegates? What makes leaders and delegates so special that they can command the masses that do the work? When they bleed, does their blood run blue? They are special, because they are willing to put their heads above the parapet, and take that sort of thing from you. For that reason, I'm willing to meander slightly away from the place I was going to anyway. The leadership has no power, other than to suggest a direction. Democracy doesn't work in this situation. Lets have a look at some possibilities: 1) The vast majority of developers want something to happen: It's probably going to happen then --- no need for a vote 2) The vast majority of developers don't want something to happen It's probably not going to happen then --- no need for a vote 3) A majority believes that something should happen, but the people required to do something about it disagree. Chances are that you won't be able to make it happen, unless someone decides to take over the difficult job and do it differently. There is a very good chance that the disagreement rises out of the fact that the majority has failed to notice a problem, that the few in the know understand because they've been doing the work in the field. Democracy would give the majority the feeling that they have the right to tell the few what to do, which they absolutely do not have. In this project, the act of taking on a difficult job gives you the right to do it in any way you see fit. If that means that you annoy enough of the developers, then you may get yourself expelled from the project, but someone else is likely to stand up and do it another way, before that happens. The fact is, that in most cases there is one way of doing things that is more technically excellent than the alternatives (this being a technical, rather than a political project), so disagreements happen less often than in normal life. Where this is not the case, it normally gets resolved by the fist person that does something about it pleasing themselves, and the rest of us not minding _too_ much. Most of the more vocal arguments on these lists seem come from people claiming to be supported by some sort of majority (often falsely) and drawing the conclusion that they have the right to tell an individual what to do. Well I don't think we have the right to tell anyone in this project what to do. Please don't assume that I mean that I think developers should be allowed to do random, destructive things. People that do random, destructive things are unlikely to be attracted to being a Debian maintainer, and if they were I think we should expel that from the project (after warning them that this would happen, if they didn't modify their behavior ). Most of us are here because we hold largely common beliefs about what Debian should be. If changing your citizenship were as easy as changing your hair style, democracy would be largely unnecessary, since people would be able to move to a country that had a government system that matched their beliefs. In a world like that, a vote by the majority against the interests of the few would not work, because the few would just move countries. That is the situation we are in. I vote ``No Democracy for Debian!'' ;-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Consesus on Linuxconf?
I was wondering if we have reached some sort of consesus on Linuxconf. The points that I see are *Linuxconf can't lose any info. --This might mean that Linuxconf will error out if it can't parse the file, if you've made private changes to it. That's the tradeoff, you take a risk that you won't be able to use linuxconf if you privately edit the file. We will work to improve the parser though to minimize that risk. --If for some reason linuxconf munges the file, you should be able to go back to the previous version easily through versioning. *Linuxconf isn't only way to configure system? (is this a point of contention?) --We should continue to provide similiar tools to what we have now to be able to configure the system. ---If we do the above, should it be interchangably b/w linuxconf configuration system and old configuration system for the same package (i.e. on one computer, I can switch easily b/w sendmailconfig and linuxconf sendmail configuation). I think that might be too difficult to pull off. We should say that you can choose for each packages b/w the old method or Linuxconf's, but shouldn't switch b/w the 2 methods for one package, at least not expecting the data to be fully transalatable. *Modules for all packages that have conf files --Is this neccesary? Can someone do a study on what the majority of conf files are, i.e. are they free flowing (i.e. don't have a set form and can be on any length), or are they a simple form with plug in variables, or are they a combination of the two. writing a module for the first case will be more difficult, while writing a module for the second case should be very easy, and we can provide an example module to show how it's done. The thirds case will probably be slightly difficult as well, though I'm not sure. Feel free to add more points that need to be covered for consesus. Shaya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm for other architectures
Brandon Mitchell [EMAIL PROTECTED] writes: Are we releasing hamm for any other architectures? I've has a few request from new testers. Also who should they contact on architecture specific problems? Thanks, Brandon Apart from some missing Packages m68k is running stable. My A4000T server, which is compiling all new debian sources, has an uptime of 106 days now. I updated it 4 times now, the last one done with apt, which was much faster and easier. Even so its stressed a lot by us (compiling stuff, testing of our dragon tool, xdm for 2 remote users, a lot of network traffic) it hasn't shown any serious problems. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
On 03-Jun-1998, Joel Klecker [EMAIL PROTECTED] wrote: At 23:38 -0700 1998-06-02, Tyson Dowd wrote: Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. Another one is that he didn't explain what dpkg-shlibdeps does. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. That isn't the right way to do it, the executables may end up depending on being run from the same directory as the one they were built with (in practice, it doesn't seem that too many packages are like that, but it's good to keep it in mind). Oops, sorry, you are of course correct. -- Tyson Dowd # So I asked Sarah: what's the serial number on # your computer? She replied: [EMAIL PROTECTED]# A-C-2-4-0-V-/-5-0-H-Z http://www.cs.mu.oz.au/~trd # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files
Michael Bramer [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] On Wed, Jun 03, 1998 at 02:25:39AM -0500, Manoj Srivastava wrote: Hi, Michael == Michael Bramer [EMAIL PROTECTED] writes: Michael I think the right place is in the *.deb-file. In the Michael control-file (like the description) or as new file in *.deb. Why do you think so? You don't give any reasons whatsoever, so this is not a technical statement, but a mere expression of personal preference. Oh yes, I see .. I personally think that is a bad idea for the folowing reasons: a) the data is harder to manipulate: as a separate file, dinstall just has to rename the file to a cache area, and use zcat and echo to generate the master sizes.gz file. As a control file, dinstall has to unpack the .deb file and extract the data. I think this not a point. dinstall get the size.gz file from the .deb file (ar -x) and put it to the cache area. I don't see the difference? (And for old .deb files: dinstall unpack the .deb file in /tmp/../ and make the size.gz-file) SO I have to downlaod 15 MB of xbooks, just to get told that it wont fit? BAD IDEA. You need the information when you install a package on your debian system. I think it is a nice to download only one file to install the package. I get often packages with ftp from a mirror and install the packages with: dpkg -i *.deb. If the the size information isn't in the debian-package, then i must download two files (NAME-VERSION.deb and NAME-VERSION.size.gz) or dpkg has no information of the size and can not make a warning message. :-( We have seperate package-functions and the interface. This is a very good. You can install package with: dpkg dselect (with use dpkg) apt (with use also dpkg) The du-information is a information like name, version, depends etc. The right place is the .deb-file. Comments? Grisu If you want only one file per package, than stuff it into the Packages.gz file (probably making a Packages_du.tgz containing Packages and du_index, and Packages.gz). If the du info is in the .deb, one has to download it to see if the file will fit and say dselect or apt can't give informations about needed size. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Manoj Srivastava [EMAIL PROTECTED] writes: Drake On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: What is the benefit of keeping packages in an unconfigured state? DrakeIt's a reminder to me that I need to configure this package still. I prefer the approach to ask questions first, and configure as it installs. If we are spending time to do this, we should do this right. In general, you can't ask all questions first; you can ask some questions, then unpack and debian-configure the packages, but then you still have to do a lot of configuration (using an editor or some configuration programs that ask questions). Think about the kernel-image postinst, generated by your kernel-package. Only some of the possible questions are really asked. So, either you ask all questions in advance, even those that are not relevant for a specific configuration. Or you supply a script for asking the relevant questions, but even that might be difficult, because the questions depend on the state of the system which might be different before installation than when the postinst is actually executed. Ian's list is a good starting point (and having the choice of being asked some questions in advance is good), though it doesn't solve the above points, and it's only focused on how can i make the current debian packages run noninteractively which is only one aspect of how can i make system installation/upgrade work better. I'd like to integrate more of the bookkeeping tasks into the debian system, like being able to display a list of warnings/errors after installation is finished, and a list of packages that still have to be user-configured. E.g., the debian configure run of autofs makes the debian installer happy, but not the user -- the configuration is not usable for most users. I don't think this user-configuration is a task that should be handled in postinst, but it would be nice if the package system would remind the user after installation be sure to look into /etc/auto.master, something like a todo-list. Btw., the 2. version of my summary article on this is still on my todo-list, I was swamped with work recently. [...] Maybe you have the luxury of having a box be unconfigured and non working when you go home. A lot of us are not so lucky. We prefer answering the questions first, and then starting the upgrade. barring bugs, the machine down time is minimized. how do you deal with existing versus new config files during an upgrade (or how would you like to deal with it)? As I said, let us solve the real issues, not apply band aids. me too ;-) ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xteddy
Awhile ago I read here of a package someone made called (I think) xteddy, which was replacement login screen for X. I have just wadded through ftp.debian and could not find it. As I just got the courage to enable xpm on my system (WOW what a pretty login screen with the debian 'logo' and the spectrum in the background changing colors!) I would like to try it. I seem to recall that someone also sub'ed TUX in there too. So please what is the URL for the download of that package? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intent to package
Since I need it for my local use anyway I think about packaging mpsql, a graphical (lesstif) frontend for PostgreSQL. However, since it uses libhelp it is not free for commercial use. So I guess it has to go into non-free. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Consesus on Linuxconf?
Shaya Potter [EMAIL PROTECTED] writes: I was wondering if we have reached some sort of consesus on Linuxconf. The points that I see are *Linuxconf can't lose any info. --This might mean that Linuxconf will error out if it can't parse the file, if you've made private changes to it. That's the tradeoff, you take a risk that you won't be able to use linuxconf if you privately edit the file. We will work to improve the parser though to minimize that risk. This will be the case with any interactive config-program build on top of existing configuration languages (even the samba configuration language is complex enough for this to be true). [...] *Linuxconf isn't only way to configure system? (is this a point of contention?) --We should continue to provide similiar tools to what we have now to be able to configure the system. ---If we do the above, should it be interchangably b/w linuxconf configuration system and old configuration system for the same package (i.e. on one computer, I can switch easily b/w sendmailconfig and linuxconf sendmail configuation). I think that might be too difficult to pull off. We should say that you can choose for each packages b/w the old method or Linuxconf's, but shouldn't switch b/w the 2 methods for one package, at least not expecting the data to be fully transalatable. It should be possible to disable the linuxconf module, and perhaps tell linuxconf to start sendmailconfig instead, or warn the user when switching configuration methods. *Modules for all packages that have conf files --Is this neccesary? Can someone do a study on what the majority of conf IMHO not nessacary files are, i.e. are they free flowing (i.e. don't have a set form and can be on any length), or are they a simple form with plug in variables, or are they a combination of the two. writing a module for the first case will be more difficult, while writing a module for the second case should be very easy, and we can provide an example module to show how it's done. The thirds case will probably be slightly difficult as well, though I'm not sure. most configuration files can be complex; take a look at the files in your /etc. How many simple and how many potentially complex files did you find? Additional points I would consider important: - how difficult is it to write a module for linuxconf for some package; can some scripting language be used? - how well does linuxconf scale (what if i have 50 configuration modules?) - how clean/flexible/modular are the concepts? Will the framework break down 3 year from now because there are so much new requirements that can't be integrated? - on which platforms could it run or made to work? (administrating a bunch of machines with the same tool would be a plus; i think it's one goal of coas) These are general questions relating to any such program. Perhaps it would be a good idea to discuss the interfaces to packages. If one could standardize that (how to put additional information into sysv-initscripts, and which information, or the module api, etc.), perhaps we could get less dependent on a specific program like linuxconf. I'd like someone to package linuxconf for debian (an experimental release), so it's easier for everyone to take a look at it. Last time I looked at it (I think it was november 1997), I wasn't very convinced of it's concepts. My impression was it's a monolith (though there is a clean interface for front ends), and I didn't like the module api very much (I experimented with a python interface module, which lets you load modules defined by python scripts, but the overall architecture wasn't very convincing). Is everything prodived by modules by now, e.g. adding users, and how much (e.g. path names) is still hardcoded and buried somewhere? I also looked at coas (and started to define a interface to front ends like in linuxconf, which is an area where coas is lacking), but it seemed like development was stalled for some time. Now v0.11 has come out, but i'm not sure if it's gaining speed (if it does i'll take up the work on it again). The concept of coas seems to be much cleaner, concentrating on infrastructure. Did anyone succeed in compiling it under debian or installing the rpm's under debian? The official compile uses libc5 and python 1.4, and the binaries in the rpm are looking for libncurses.so.4, a libc5-readline in /usr/lib, etc. Btw., is there any document about the outcome of the BOF on LSB at Linux-Expo? It would be nice if installing a rpm with alien under debian would be easier than recompiling the source. ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files
On Wed, Jun 03, 1998 at 02:23:02PM +0200, Brederlow wrote: Michael Bramer [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] On Wed, Jun 03, 1998 at 02:25:39AM -0500, Manoj Srivastava wrote: dinstall get the size.gz file from the .deb file (ar -x) and put it to the cache area. I don't see the difference? (And for old .deb files: dinstall unpack the .deb file in /tmp/../ and make the size.gz-file) SO I have to downlaod 15 MB of xbooks, just to get told that it wont fit? BAD IDEA. Oh no. If you update or download with apt or dselect, then apt or dselect get Packages_du.gz befor it download the .deb files. So it can check the space on the disk and make warnings. (dinstall make the Packages_du.gz (like Packages.gz) from the .deb files. dinstall get size.gz from the 'news' .deb files or make a size.gz from the 'old' deb files) But if you download from the ftp-server by yourself and install the dep file with dpkg, then you haven't a disk check. Only if the du information is in the deb file, dpkg can make a check. You need the information when you install a package on your debian system. I think it is a nice to download only one file to install the package. I get often packages with ftp from a mirror and install the packages with: dpkg -i *.deb. If the the size information isn't in the debian-package, then i must download two files (NAME-VERSION.deb and NAME-VERSION.size.gz) or dpkg has no information of the size and can not make a warning message. :-( We have seperate package-functions and the interface. This is a very good. You can install package with: dpkg dselect (with use dpkg) apt (with use also dpkg) The du-information is a information like name, version, depends etc. The right place is the .deb-file. Comments? If you want only one file per package, than stuff it into the Packages.gz file (probably making a Packages_du.tgz containing Packages and du_index, and Packages.gz). If the du info is in the .deb, one has to download it to see if the file will fit and say dselect or apt can't give informations about needed size. I say: Put the du information in the .deb files and make (on master) from this the packages_du.gz file. In this case all installer (like apt and dselect) can download packages_du.gz and make a check befor it download all .deb files. But also dpkg can check the disk space (with the information in the .deb file) If we have du information only on a seperate file, only dselect and apt can make a check :-( Grisu pgppVVNZtA4pz.pgp Description: PGP signature
Re: On adding size info to Packages files [very long]
Hi, Brederlow == Brederlow [EMAIL PROTECTED] writes: Brederlow The size file should be generated by the server. Here are Brederlow the reasons: I am (perhaps unnecessarily) worried about time requirements Brederlow 1. The upload should be unpacked to check if the gz is not Brederlowcorrupted. (Far to often some Package is broken) This would be a lintian check. It is better done on the maintainer machine. Brederlow 2. The du indexes should be gathered and pipe into one file to gain Brederlowfar better compression. They shall be, for the Sizes.gz files (analogous to Packages.gz file). The reason to have them in a separate dir is that if one package changes, it is easier to replace a sizes file, zcat all sizes files into a big one, re-gzip that, and get a new Sizes.gz file. Brederlow 3. Maintainer will forget to include a du index or have different Brederlowblock sizes. This can be made policy and a lintian check. We have to trust the maintainers a trifle ;-) Brederlow The Server should hold a unpacked Version of each Package's du index Brederlow and after processing all uploads it should combine and pack them. Quite so. manoj -- Knowing that one is dear to oneself, one should guard oneself well. For one out of the three watches of the night a wise man should keep watch. 157 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On 3 Jun 1998, Manoj Srivastava wrote: Hi, Philip == Philip Hands [EMAIL PROTECTED] writes: Philip No, because democracy is inefficient in our case. Inefficient or not, if it is the only thing that works ... As Philip and others have pointed out, that is as feable an argument as has ever been made. I simply doesn't work for Debian. If you look at the percentage of the list traffic taken up with the How Shall We Organize Orselves type threads, as compared with the percentage of What do we need to DO to GET HAMM OUT THE DOOR? (and YES there is a need to yell about this), and you will see that we are currently wasting large quantities of Debian Bandwidth doing pure politics and little else. We must recognise two things: 1. Debian functions as a Goal Oriented Anarchy. (Bruce called it Herding Cats) 2. The only reason it is functional is that all the cats have the same goals (for the most part). The best way to achieve goals in this environment is to discuss the goals, not the best way to get everyone to work toward them. If the goals are well thought out (read well discussed) we must rely on everyone doing their part toward those goals. Whenever we divert our attention from these tasks we loose ground. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On Wed, Jun 03, 1998 at 11:17:15AM +0100, Philip Hands wrote: [ This post is a on the long side, and probably not of interest to many (sorry). It comes up with the conclusion that Debian and Democracy don't mix. ] yes it is long...as such I wont quote it all :) Why? Because even though we do all the work, the masses are too dumb to do their own masters? We need a all knowing, all powerful group of people to tell us how to act? What cventury are we in now? No, because democracy is inefficient in our case. I would go a step further and say democracy is always inefficient, in fact it is inefficiant by design [snip -good points but I have no reply to them] We developers are not under anyone's power, since we can always do our own thing, or leave the project, so the protection democracy gives is unnecessary and adds wasteful overhead to the decision making process. I just made another post here efore I read this...as I had said, I think democracy can work for debian...what I feel I left out was that I agree there Personally I have no interest in the politics of the project. I try to help out and plan in the future to do more once things in my life settle down a bit for the simple reason that i use debian and like it...I want to help out I want to make the system better, and give everyone (including myself) more choices within debian. They are special, because they are willing to put their heads above the parapet, and take that sort of thing from you. For that reason, I'm willing to meander slightly away from the place I was going to anyway. The leadership has no power, other than to suggest a direction. I think that is the best description I have ever read of what the leadership should be and how things should work. Democracy would give the majority the feeling that they have the right to tell the few what to do, which they absolutely do not have. That is the major falling of every democracy, I think that for a group like debian this is not quite as bad as it has shown itself to be in other places. The fact is, that in most cases there is one way of doing things that is more technically excellent than the alternatives (this being a technical, rather than a political project), so disagreements happen less often than in normal life. This is the main reason I think democracy, or really any system, could work for debian...the obvious downside being the enormous overhead of democracy Please don't assume that I mean that I think developers should be allowed to do random, destructive things. People that do random, destructive things are unlikely to be attracted to being a Debian maintainer, and if they were I think we should expel that from the project (after warning them that this would happen, if they didn't modify their behavior ). I agree...and hope that while I am with the project I hope that I shall never see the day when this is needed. Most of us are here because we hold largely common beliefs about what Debian should be. If changing your citizenship were as easy as changing your hair style, democracy would be largely unnecessary, since people would be able to move to a country that had a government system that matched their beliefs. For that to happen, governments would in effect be truely powerless over individuals, since they can just opt to leave (or possibly start their own government). This favors personal freedom, and personal freedom is what all governments are fundamentally opposed to (whether they admit it or not) In a world like that, a vote by the majority against the interests of the few would not work, because the few would just move countries. That is the situation we are in. That is one of the few reasons debian could use democracy I think... AT least if a person very strongly feels one way on an issue, and the majority vote against it...that person can leave and find a place where their views are more apreciated and used. I vote ``No Democracy for Debian!'' ;-) I have to agreedemocracy is at BEST overkill, if applied in a general sense. If it were applied ina a way such as having a vote over what general suggestion of direction the leaders should make then that I can see... anything more specific is at best overkill...and at worst a hinderance to the project as a whole. However, as I stated I am not tewrribly interested in the politics of the system and much more in just helping to better the system and improve its technical excellence, to give back to the community. -Steve pgpJYgGmIkgZp.pgp Description: PGP signature
Intend to package xlogmaster
Hallo all, as work continues, here´s my next project: I would like to package xlogmaster available from http://porter.desy.de/~greve/xlogmaster/ I have to get a statement from the author which License and copyright to apply (not the single words copyright or license in the archive! :-( ). --- [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 2048/E451C639 Jens Ritter Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
Hi,
Dale == Dale Scheetz [EMAIL PROTECTED] writes:
Dale We must recognise two things:
Dale 1. Debian functions as a Goal Oriented Anarchy.
Dale (Bruce called it Herding Cats)
Dale 2. The only reason it is functional is that all the cats have the
Dale same goals (for the most part).
It has gotten to the point that the cats have to have a
process to recognize the goals. The constitution provides the
process.
Also, it is easy to define fuzzy goals:
a) we need hamm out the door now
b) we neeed to release more often, and on schedule
(I like guys proposal of an updated stable pool that can be
tested continuuls, frozen, and released fast -- since there are
never any release critical bugs in the stable pool, the current
delay does not occur)
c) we need to cater to unattended installs/ replication in compute
farms
(Ians proposal of a question asking spec was a good
start. Linuxconfig and COAS are also promising)
d) We eed to get a better front end than dselect
APT is coming along
e) We need to do a size-required-for-installation thing
.
n) make debian the best free distribution in the whole darned world
...
x) beat every other OS in market share.
There. Goals galore. If you want more goals, just ask. I can
create goals by the minute, no problems. Are we satisfied now?
Hardly. For goals are nothing unless they can be fleshed out. Goals
by themselves are vapourware.
Since people want to discuss goals, let us get this over and
done with. Email me goals, and I promise to have a 100 by the
weekend. Then maybe we can get off and try and actually *DO*
something, like design and implementation, rather than sit around
talking goals.
manoj
--
Date: 6 Mar 90 11:07:32 GMT From: [EMAIL PROTECTED]
(Andrew Vignaux) @l = split
(/(..)/,'1a7r4J1n0a7e7c1o8n248o1t4u8v4s7.207l27547a7n7g1h'. '0
511e3h7.8i564t3a6P1r7p8c8e6e3c3k7e3e533r7r286r6l4 6 1 8,7l7 3,');
srand; $_=3*int(rand(2))+2; /^$_/; foreach (split(//,g))
{/^$_/;print g;} print \n; sub g
{join('',grep(s/^.//,grep(//,@l)));}
Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
Hello! On Tue, Jun 02, 1998 at 09:19:11PM +0200, joost witteveen wrote: The document authors already can enforce a lot of things, keeping the document free: [...] I want to hear valid reasons why this is not enough before I even think about non-free documents in main! Uhm -- just one reason: GPL (the text) is non-free: you are not allowed to modify it (from the GPL, first few lines): Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Nah! You can't change the copyright of a program, so what? You can derive a new copyright from the GPL, but you mustn't name it GPL. Changing the name is enough, because license textes themselves are not copyrighted in the normal sense (IIRC). OK, that may well be true. But still the text of the GPL is clear: you are not allowed to change it, whether you change the name of your cahnged version or not. It may well be that in some countries, becaus the GPL is a (software) licence, such claims are illegal, and that thus in those countries one can change the tekst of the GPL (possibly changing the naem of the document). But that really only applies to those countries where by law licences are changeable documents. And it clearly is agianst the wisxhes of those who wrote the GPL. As I stated in my original mail, requiring a name change is okay and does not make a document non-free IMHO. That is perfectly OK for me too. But the GPL tekst doesn't say one is allowed to change the text, if one also changes the name. The GPL just say one isn't allowed to change it. Fortunately (if I'm correct) the GPL does not _FORCE_ us to include a copy of the GPL document with debian -- so there _is_ a way to distribute a ``free'' debian: `rm /usr/doc/copyright/*GPL'. (and maybe put a note there, saying that we cannot distribute the GPL due to licence problems, but it can be found by writing to ...). Actually, I'm more serious than it may seem. Yes, I realise it's a bit harsh to remove it (and other references) from Debian, but if that helps to make the FSF distribute the GPL with a different licence, then it's a good thing. This is not necessary, as this has nothing to do with software freeness anymore. The point is that you can't change the copyright of programs (this does not make them non-free!), OF cource I agreee with you. And by typing: sed -e s/e/E/g /usr/doc/copyright/GPL /tmp/my-changed-gpl I wouldn't be changing the copyright of any GPL-ed programme -- and I don't want to change those copyrights. I just want to be allowed to execute the above command. The text of the GPL says I'm not allowed to do so. Where is the problem? The problem is that the GPL is a legal text, and a sequence of bytes. We want to have the right to change the sequence of bytes, not the legal text. If we encode the GPL in unicode instead of ASCII, is this a infringement against the quote above? Yes, unless you call a unicode version verbatim. Yes, I don't want to change the licence of any existing GPL-ed programme. I do want to be able to change the docuemnt, possibly for my own programmes. (Though I'll stick with pure GPL for now). Let's not get bizarre here. I'll try to summarize: 1) A software entity that forbids to change the copyright is not non-free becasue of this clause (if this would be true, we could only ship PD software). That I agree with: but the above quote din't just say you aren't allowed to change the document called GPL, or COPYING, beloging to a programme. The quote sais a lot more: It also says you are not allwoed to change the GPL _at_all_. 2) Requiring a name change is sufficient to cope with this problem. If I'm allowed to issue the sed-command above, then I'm all happy. The problem is that the GPL does not allow me to issue that sed-command. I think we both agree on the main issues, we just read the quote of the GPL different. You seem to read: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. as saying change this document as you like, but if you change it, also change the name of the document. However, I see no reference to the name of the document there, nor do I see any reason wy the above quote alowes me to change the the GPL at all, with or without chaningt the name. Also, I think the quote is quite clear: DO NOT CHANTGE THE DOCUMENT. whether you change the name or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intent to package v2html, license question
I intend to package v2html, the verilog to HTML converter. I have a question about the license though: Would the following be OK to allow it in main? -- Steve PhillipsPhone: (715) 830-1200 x109 Silicon Logic Engineering, LLPFAX: (715) 830-1887 131 South Barstow Street, Suite 600 Mailto:[EMAIL PROTECTED] Eau Claire, WI 54701 Web: http://www.siliconlogic.comv2html Conversion Software Limited Copyright Licence BACKGROUND The accompanying v2html conversion software (the software) is a copyrighted work. This document describes conditions under which the software can be copied, modified and distributed. All rights, including copyright, in the software are retained by the owner(s) as identified in each software file. Subject to the conditions described below, you may modify source files included with the software and distribute the modified versions. The software accompanying this notice may include such derivative works. CONDITIONS FOR AUTHORIZED COPYING, MODIFICATION AND DISTRIBUTION If you agree to all of the following conditions, you may copy, modify and distribute the software subject to these conditions. You do not need to agree to these conditions. However, if you do not agree to all of the following conditions, you are not authorized to do anything with regard to the copyrighted work that is within the exclusive domain of a copyright owner, such as copying, modification, and distribution. (1) No fee (monetary or otherwise) may be charged for the software or any derivative work (whether in exchange for copying, distribution, use, or otherwise). (2) The software includes copyright notices, references to this document, and warnings concerning the intended use of the software. All such notices are to be included in all copies of the software. Any code copied or moved to a file not having such notices must be accompanied by such notices. Notices that are displayed to a user during execution of the software are to remain intact. (3) This document may not be modified. A copy of this document must be included with each copy of the software, including derivative works. (4) Failure to abide by these conditions terminates any rights that you may otherwise have had under this licence. (5) NO WARRANTY: The software has NO warranty from anyone; for example, there is NO warranty that the software is error free and there is NO warranty with respect to infringement of patents, copyrights or any other intellectual property rights. The software is provided AS IS. NO support is provided for the software. THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE SPECIFICALLY DISCLAIMED. (6) LIMITATIONS OF REMEDIES AND LIABILITY: In no event shall Hewlett-Packard be liable for direct, indirect, special, incidental or consequential damages (including lost profits), whether based on contract, tort or any other legal theory. (7) DERIVATIVE WORKS: In this document, the phrase derivative work is intended to include only those works that include sufficient copyrightable material from the software such that the derivative work would be a copyright infringement if made without authorization of the owner of the copyright in the software.
Re: Intent to package v2html, license question
On Wed, 3 Jun 1998, Steve Phillips wrote: I intend to package v2html, the verilog to HTML converter. I have a question about the license though: Would the following be OK to allow it in main? No way. It says you can't charge for distribution. So CD people can't even put it on their CDs.. That's way out. J /+---+-\ | 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. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On Wed, Jun 03, 1998 at 12:59:50PM -0500, Stephen Carpenter wrote: No, because democracy is inefficient in our case. I would go a step further and say democracy is always inefficient, in fact it is inefficiant by design Indeed, there is a reason why in the US a republic was formed by our founding fathers and not a democracy. How things have shifted I don't know, but they feared anything resembling a democracy (cf. The Federalist Papers) for the same reasons why our government is as it is today. A republic would be a better choice. I am however just one voice and one choice, so I kinda don't suspect these opinions to change the course of Debian. I do think however that now is a bad time to discuss it in detail. Right now hamm is more important because the uses are more important than our squabbles over political structure. pgpmXv08ByFD6.pgp Description: PGP signature
Re: Documentation Freeness (Re: Packages to be removed from hamm)
Joost Witteveen [EMAIL PROTECTED] wrote: OK, that may well be true. But still the text of the GPL is clear: you are not allowed to change it, whether you change the name of your cahnged version or not. You're saying that all those people who have licensed their software under modified versions of the GPL are breaking the law? Do you have any basis for this statement? I think there's a very strong distinction between changing the license under which software is released, and changing the corresponding document. -- Raul, wondering if this has anything at all to do with release critical bugs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On 3 Jun 1998, Manoj Srivastava wrote: Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale We must recognise two things: Dale1. Debian functions as a Goal Oriented Anarchy. Dale(Bruce called it Herding Cats) Dale2. The only reason it is functional is that all the cats have the Dale same goals (for the most part). It has gotten to the point that the cats have to have a process to recognize the goals. The constitution provides the process. The constitution does not provide a process, it defines one. It is the developers in this group, working together, who create process. It is primarily this mailing list that provides access to that process. Also, it is easy to define fuzzy goals: Defining fuzzy goals is not the best way to approach this problem, so why do you wish to waste time in this fashion? a) we need hamm out the door now b) we neeed to release more often, and on schedule (I like guys proposal of an updated stable pool that can be tested continuuls, frozen, and released fast -- since there are never any release critical bugs in the stable pool, the current delay does not occur) c) we need to cater to unattended installs/ replication in compute farms (Ians proposal of a question asking spec was a good start. Linuxconfig and COAS are also promising) d) We eed to get a better front end than dselect APT is coming along e) We need to do a size-required-for-installation thing . n) make debian the best free distribution in the whole darned world I always thought this was #1 (or 'a)' if you insist) There. Goals galore. If you want more goals, just ask. I can create goals by the minute, no problems. Are we satisfied now? Hardly. For goals are nothing unless they can be fleshed out. Goals by themselves are vapourware. Hense the need for discussion, a key word you seem to have forgotten. Since people want to discuss goals, let us get this over and done with. Email me goals, and I promise to have a 100 by the Such discussions are never over ;-) weekend. Then maybe we can get off and try and actually *DO* something, like design and implementation, rather than sit around talking goals. Design and implimentation follow goals, not the other way around. A discussion requires setting goals and determining just what is necessary from each of us to make these goals attainable. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On Wed, Jun 03, 1998 at 11:17:15AM +0100, Philip Hands wrote: Democracy would give the majority the feeling that they have the right to tell the few what to do, which they absolutely do not have. That is the major falling of every democracy[...] There are many different types of democracies. Universal franchise democracies are *very* dangerous, for reasons well known (and easily seen) by anyone interested in the matter. On the other hand, proportional (or corporate) democracies can be remarkably stable. In the case of Debian, a pretty straightforward democracy can be implemented by voting by shares, where one share == one package. You could also weigh shares by category; e.g., an essential package is worth 5 shares, an optional package is worth 2 shares and an extra package is only worth one. That keeps control in the hands of the people who do the work, and they're the ones most likely to know what needs to be done and the true cost of trivial changes. Also, since the voting majority rests in the hands of relatively few individuals, they can generally lead by consensus amongst themselves. If someone disagrees with their policies, they can easily gain a louder voice by carrying a greater share of the load. Since I haven't had time to work on the Hesiod package for several weeks (not even to recompile it with libc6), I have zero shares and you're certainly free to ignore me! :-) Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
On Wed, 3 Jun 1998, Joost Witteveen wrote: sed -e s/e/E/g /usr/doc/copyright/GPL /tmp/my-changed-gpl I wouldn't be changing the copyright of any GPL-ed programme -- and I don't want to change those copyrights. I just want to be allowed to execute the above command. The text of the GPL says I'm not allowed to do so. It can't. You haven't signed the GPL. So the GPL *cannot* tell you what to do. This is a major piece of FUD, so I'll try to clear it up, even though I understand it imperfectly myself. I draw the substance of this from the GPL itself. 1) The GPL is a License, or a contract. None of us have signed this license, so we are not bound by anything it says. 2) A piece of work which happens to be protected by the GPL, is a copyrighted piece of work. This means that, a priori, we may not copy it. *However*, the author of this piece of work has chosen to cede some of his copyright. He has set out conditions under which we may copy it. This is his right, as copyright-holder. The conditions he has chosen are the GPL. We are only bound by the GPL at the point at which we decide to do something which would otherwise be illegal - I.e. copy the work. (not the GPL). Also note the following paragraph: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. The GPL is about *copying* not about using. So it does not restrict use. Some other condition imposed on you by the author may. -- Now, the GPL itself is a document. And as such it is copyright the FSF. It says so at the top of the GPL: GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. This does in fact mean that the GPL is copyrighted. And, since the copyright holders have not given us the right to create derived works, we don't have it. Now, unicode would be fine, because a unicode copy of the GPL is 'verbatim'. So is EBCDIC. So is printed. The copyright applies to the words, not the bytes. Personally, I'd argue that sed 's/e/E/;' is also verbatim (albeit now mispunctuated). Also, note that you can do anything you like to the GPL 'in the privacy of your own home'. Copyright restricts distribution, not use. Raul wrote, in another email that just arrived as I write this: You're saying that all those people who have licensed their software under modified versions of the GPL are breaking the law? Do you have any basis for this statement? Personally, I find that a clear indication of the above quote. A license which is merely inspired by the GPL is clearly fine. A license which actually quotes some parts of the GPL, would appear to be quoting from a copyrighted document, which requires the permission of the copyright holder. Incidentally, it would be fine to say : This program is covered under the GPL, except for point X, which I exempt you from. As long as the GPL was included in full (verbatim). I think there's a very strong distinction between changing the license under which software is released, and changing the corresponding document. You're quite right. Of course there is. Changing the GPL in your own home cannot be made illegal. Unless you have signed a document agreeing not to - and none of us have. Distributing modified versions of the GPL which claim to be the GPL is clearly illegal (I hope none of you would argue with that). However, and very worryingly, it appears that the FSF copyright on the top of the GPL means that creating a derived work requires the consent (explicitly) of the FSF. Hmm... I wonder if there's a public document somewhere in which the FSF say they're happy for people to derive works from the GPL? Otherwise, the GPL is non-free. Humph. Talked myself into a corner. Someone dig me out? Jules /+---+-\ | 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. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe.
Re: Intent to fix base-passwd
On Wed, Jun 03, 1998 at 10:18:40AM +0100, James Troup wrote: Christian Meder [EMAIL PROTECTED] writes: while testing the base packages I hit the critical bugs surrounding the update-passwd binary contained in base-passwd. Uh, which critical bugs? --sanity-check now works as expected, is run by default and update-passwd is no longer run automatically, it has to be run by the user if it is to be used. Ok. So 19839, 19946 and the related passwd bug 21275 should be considered fixed ? Great ;-) Brian, are you listening ? The postinst should be changed to something along the lines: update-passwd --sanity-check update-passwd -n Ask user if changes are ok. If yes update-passwd No, please don't do this. Even if you do fix all the known bugs, it's _way_ too late in the game to put an automatic call of update-passwd back in the postinst. I agree totally. My only remaining concern is the fact that update-passwd was intended as helper utility to keep passwd/group uptodate but it's still somewhat broken. passwd/group are no conffiles anymore. Everybody who upgrades won't notice that passwd/group have changed because the usual 'want to keep your version of conffile'-kind of dialog won't happen anymore. update-passwd isn't run by default, too. The majority of systems will keep their bo-passwd/group files because the users aren't notified that passwd/group have changed. I checked the diff: msql, gnats and amanda will be affected (msql entry missing, gnats entry wrong and backup entry wrong). Suggestions what to do ? Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New Project: COPYRIGHT HOWTO.
Hallo all, as a lot of us developers have to deal with copyright problems, I would like to start this (hopefully) littly project. I would like to write a COPYRIGHT HOWTO, which might be send to authors of software, which a) do not state what copyright is associated with their software and b) who do not use a free (enough) license. What should be in there: 1. A discussion what is necessary to constitute a Copyright and License for a program (Do you have to state copyright in every file, is a COPYRIGHT file in the top directory enough, is a Copyright line in an LSM file enough, etc.). 1a. Why to make the effort. 2. A brief discussion of what does free mean in the software sense. 2a. Why to make it free. 3. A brief discussion of some of the different licenses. 3a. Some of the licenses. _4._ Big disclaimer, as we are not lawyers. :-) As I haven´t got enough knowledge to write this whole thing, I would like to have some input. Any hints and pointers to web sites are greatly appreciated. Below is a short list of urls attached, where I found some information about this theme (and still have to read :-( much). Feel free to modify the list above. Maybe you´ve got some other information regarding this, please send them to [EMAIL PROTECTED], or [EMAIL PROTECTED] (or to this list) TIA, Jens P.S.: Do we need something like this? http://sunsite.unc.edu/pub/Linux/LICENSES/theory.html http://www.fsf.org/philosophy/why-free.html http://www.fsf.org/philosophy/categories.html http://arl.cni.org/info/frn/copy/treaty.html For german readers: http://www.yahoo.de/Computer_und_Internet/Internet/Politik/Recht/ --- [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 2048/E451C639 Jens Ritter Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
Jules Bean [EMAIL PROTECTED] wrote: Talked myself into a corner. Someone dig me out? Hmm, you raised some good points I hadn't thought about... How about this quote: To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. Which is to say, it may not be possible to allow changes to the GPL without making it less free. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intend to package xlogmaster
Jens Ritter [EMAIL PROTECTED] writes: Hallo all, as work continues, here´s my next project: I would like to package xlogmaster available from http://porter.desy.de/~greve/xlogmaster/ I have to get a statement from the author which License and copyright to apply (not the single words copyright or license in the archive! :-( ). But in the LSM (which is not part of orig.tar.gz): CopyPolicy1 =Use, copy, modify, and distribute this software and its CopyPolicy2 =documentation for any purpose is granted without fee. Is that enough? --- [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 2048/E451C639 Jens Ritter Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to fix base-passwd
Brian, are you listening ? Yes. I get my reports directly from the bug system so if it gets updated there my reports will reflect that. Brian ( [EMAIL PROTECTED] ) --- the difference between theory and practice is less in theory than in practice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
Hi, Bear == Bear Giles [EMAIL PROTECTED] writes: Bear On the other hand, proportional (or corporate) democracies can be Bear remarkably stable. In the case of Debian, a pretty straightforward Bear democracy can be implemented by voting by shares, where one share == Bear one package. You could also weigh shares by category; e.g., an essential Bear package is worth 5 shares, an optional package is worth 2 shares and Bear an extra package is only worth one. Prolificity is a remarkably bad metric of competence too. We need not only people who do the work, we also need to give importance to the quality of work performed. Cookie cutter packages should not count as a large complex package does --- however, I am suspisious of simplistic metrics like this. I figure that peole who do the work, and are competent, would be paid more attention to during a discussion. And hence may influence a vote. I may bge all wet though, and extremely vocal people like me may well over whelm discussions. In any case, no one has really proposed a participatory democracy for Debian. The proposal is for a project leader, and delegates of that authority, and really, developers maintain full editorial control over their packages. There are checks and balances instituted for all the powers, but by no means is it an athenian democracy. I am off to play zangband. manoj -- We're here to give you a computer, not a religion. attributed to Bob Pariseau, at the introduction of the Amiga Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
On Wed, Jun 03, 1998 at 09:58:03PM +0200, Joost Witteveen wrote: OK, that may well be true. But still the text of the GPL is clear: you are not allowed to change it, whether you change the name of your cahnged version or not. I'll mail RMS about this and come back to this list when I get an answer. Thank you, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Report on Successfull Debain 2.0 installation
Hi, I send this message yesterday, but perhaps it did not quite make it through, at least I did not notice it on the list... I successfully installed Debian 2.0 on Gateway 2000 computer (P-166) using installation disks 2.0.6. First of thanks for the nice job! There were no real problems and everything went very smoothly. When kernel found CDROM, all partitions on hard drive and even Tape drive I was very impressed. I made only a couple of errors: one should use HAMM distribution instead of STABLE when setting up FTP ACESS in DSELECT mode, but I should've known that. Secondly the ethernet card 3C905 was not explicitly listed, but we found in no time that one should use 3C59x. Anyway total installation of debian on running NT machine (to make it dual boot) took about 2.5 hours, which included installation of almost everything important: network, X, WinManager with nice buttons and menus, LILO and so on. It also happend that I did not know quite well all the details of the hardware of the computer at the time, but it still did not stop us. gmp-mouse-test came very handy. After all I would say that installation disks are a great achivement. My colleague who watched all this procedure still in doubt that he could repeat it by himself on his home computer, but I hope it does not seem to him totally impossible. I hope to install Debain 2.0 on at least one more computer PII-266 from scratch soon. Anything special I should look for? Thank you for the effort, Sasha. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
On Wed, 3 Jun 1998, Jules Bean wrote: Changing the GPL in your own home cannot be made illegal. Unless you have signed a document agreeing not to - and none of us have. Distributing modified versions of the GPL which claim to be the GPL is clearly illegal (I hope none of you would argue with that). However, and very worryingly, it appears that the FSF copyright on the top of the GPL means that creating a derived work requires the consent (explicitly) of the FSF. Hmm... I wonder if there's a public document somewhere in which the FSF say they're happy for people to derive works from the GPL? Otherwise, the GPL is non-free. Humph. Talked myself into a corner. Someone dig me out? I can hand you a shovel ;-) Trying to decide whether a copyright is free or non-free is a mistake. 1. It isn't software. Even so, the GPL (as an example only) clearly says you may distribute verbatim copies (in fact it demands that you do so). The only use you can possible put the document to is that of a license (which implicitly fixes the document as unchanging) as intended by the author. 2. Modification is necessary for the freedom of software, but that freedom is undermined if a license or copyright becomes mutable. In fact, in neither case, are you restricted from providing the copyright material intact, and providing something else (like a diff for instance) to allow the end user to read your license. While this makes sense for a program's source code, it makes little sense for a copyright. If you really don't want that license, then write your own! Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
Hi, What new and improved features would we forego if you released a mirror28 package? I guess I will have to install 2.9 to see if I'm happy with it. Perhaps you could persuade the author to add support for restarts on partially downloaded files, and any other desirable patches that are not included in 2.9. Dirk Eddelbuettel [EMAIL PROTECTED] writes: Bob I would like to see this feature continued if it isn't in 2.9-1 Bob by default. Note that the license currently states that distributing modified versions of mirror is not koscher. There were way more patches, big and small. Maybe I should release a mirror28 package which preserves these ? Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
