Re: Packages should not Conflict on the basis of duplicate functionality
the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that - our way is to encourage people to learn to do it for themself by not trying to hide the fact that knowledge and experience is required (not just optional or would be nice but absolutly required) You don't think that you only can have one daemon for a particular service and it's going to be turned on by default is representative of the we-know-better-than-you attitude?
Is XEmacs nonfree?
[I searched the archives, but didn't find a previous discussion about this; if I missed it, please just point me in the right direction. Thanks.] I've been using both XEmacs(20) and Emacs(20), and while investigating some of their differences in behavior I stumbled upon http://www.xemacs.org/About/XEmacsVsGNUemacs.html which quotes RMS as having written (no date was specified): ... But in another sense it is not GNU software, because we can't use XEmacs in the GNU system: using it would mean paying a price in terms of our ability to enforce the GPL. Some of the people who have worked on XEmacs have not provided, and have not asked other contributors to provide, the legal papers to help us enforce the GPL. I have managed to get legal papers for some parts myself, but most of the XEmacs developers have not helped me get them. ... But this is worse than competition--it is unfair competition. The XEmacs developers can and do copy code they like from Emacs. If I could copy the code I like from XEmacs in the same way, at least the rivalry would be fair. But I can't do that't, because substantial parts of XEmacs don't have legal papers, or don't have known authors. ... Is that still an accurate description of the legal status (from FSF's perspective) of XEmacs, and if so, shouldn't we move it to non-free?
Re: Is XEmacs nonfree?
On Thu, Sep 30, 1999 at 12:54:32AM +, David Coe wrote: Is that still an accurate description of the legal status (from FSF's perspective) of XEmacs, and if so, shouldn't we move it to non-free? The FSF does only include code in GNU programs if the author assigns the copyright to the FSF by signing a paper. This goes for all substantial contributions to GNU programs. So, if you want to include a few dozen of lines to fileutils, textutils, bash or whatever, you have to assign the copyright to the FSF, so they can defend the code for you. Debian does not require legal papers from contributors, we just don't care and hope that our ass is covered by our good intentions (we act responsible and in good faith). No problems with XEmacs. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 08:50:00PM -0400, Clint Adams wrote: the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that - our way is to encourage people to learn to do it for themself by not trying to hide the fact that knowledge and experience is required (not just optional or would be nice but absolutly required) You don't think that you only can have one daemon for a particular service and it's going to be turned on by default is representative of the we-know-better-than-you attitude? no, because debian doesn't fuck up configuration by forcing you to go though some stupid and limited GUI interface (try doing something non-standard with network interface setup on RH and you'll know what i mean - you can't do it...actually, you can if you spend enough time figuring out their setup but you risk that your custom mods will be blown away the next time someone runs the stupid GUI configurator). debian's attitude is: if you want something different, DIY. and more importantly, it lets you DIY. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
debian's attitude is: if you want something different, DIY. and more importantly, it lets you DIY. Err.. what Unix DOESN'T let you DIY?
Re: Is XEmacs nonfree?
On Thu, Sep 30, 1999 at 12:54:32AM +, David Coe was heard to say: [quoting RMS] But in another sense it is not GNU software, because we can't use XEmacs in the GNU system: using it would mean paying a price in terms of our ability to enforce the GPL. Some of the people who have worked on XEmacs have not provided, and have not asked other contributors to provide, the legal papers to help us enforce the GPL. I have managed to get legal papers for some parts myself, but most of the XEmacs developers have not helped me get them. ... But this is worse than competition--it is unfair competition. The XEmacs developers can and do copy code they like from Emacs. If I could copy the code I like from XEmacs in the same way, at least the rivalry would be fair. But I can't do that't, because substantial parts of XEmacs don't have legal papers, or don't have known authors. ... Is that still an accurate description of the legal status (from FSF's perspective) of XEmacs, and if so, shouldn't we move it to non-free? It looks to me like he's not concerned with the free-ness of the XEmacs code, but rather with the fact that it hasn't had its copyright assigned to the FSF. He doesn't want to include non-FSF-copyrighted code in the main Emacs branch, as I understand. I guess that would keep the FSF from defending the copyright it in court. (?) Anyway, he seems to think so. :-/ Daniel -- I've struggled with reality for thirty-five years, but I'm glad to say that I finally won. -- _Harvey_
Re: Can I have a package with no real name of upstream maintainer?
David Starner [EMAIL PROTECTED] writes: On Wed, Sep 29, 1999 at 04:32:08PM +0100, Philip Hands wrote: Thomas Schoepf [EMAIL PROTECTED] writes: On Wed, Sep 29, 1999 at 12:18:01PM +0200, Christian Surchi wrote: I'm packaging tkpgp, from munitions.vipul.net archive. The upstream maintainer doesn't want reveal his real name and wants only tftp as name and an email address. The package is release under GPL. Is this possible? The upstream author seems to be a bit strange (or paranoid) but technically/legally that's no reason to not include the software. This should probably be looked at be the debian-legal folks, but it strikes me that putting the GPL on something, without having a real copyright holder, either means that nobody has been granted permission to distribute it, or that the GPL conditions could never be enforced (since there is no author to sue people that infringe against the GPL) There is an author, who goes by the name of tftp. At least in the US, it's entirely legal for tftp to go by any name he wants for whatever purpose, as long as he's not out to defraud anyone. Do you think you could have made copies of Primary Colors, just because the author went by Anonymous? Or that the publisher couldn't make copies, because they didn't know his real name (assuming they didn't)? I'd imagine that the publisher holds the copyright in that case, so the analogous situation would call for SPI to end up as the copyright holders. I doubt very much that it says Copyright (c) Anonymous, because that would effectively give you the right to make copies of it, because there would be nobody to sue you for infringing. Cheers, Phil.
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 09:26:39PM -0400, Clint Adams wrote: debian's attitude is: if you want something different, DIY. and more importantly, it lets you DIY. Err.. what Unix DOESN'T let you DIY? read the rest of my message. the bit that ranted about unix's that get in the way of DIY. RH is one. sun's Netra is another...both are examples of how NOT to do configuration management on unix. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 09:57:53PM +1000, Drake Diedrich wrote: One way to minimize the harm of unintentionally installed or misconfigured daemons would be to add a default ipchain/ipfwadm policy rejecting all TCP SYN (incoming initialization) and non-DNS UDP packets except those from localhost. This approach (adding complexity to the active system) is a hack. There are situations where it's appropriate, but in most cases it's just one more thing to mess up, or one more thing where the user would have to wrestle with semi-automated configuration. The debconf solution is much better. -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
read the rest of my message. the bit that ranted about unix's that get in the way of DIY. RH is one. sun's Netra is another...both are examples of how NOT to do configuration management on unix. No. You're talking about doing something your way and then having it wrecked by the RH/whatever way. And if you decide to do something your way in conflict with the Debian way, Debian may wreck your work too. If I'm running /usr/local/sbin/sillycommercialpop3d, or /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck, and I want to install php72-pop3 which Requires pop3-server, and I naively apt-get install php72-pop3, not thinking it would require a local pop server or thinking that my pop server should be sufficient, I'd probably end up with a nice little tagalog pop server that installs itself in inetd and steals the port. There are two simple solutions to this. Either you do it the Debian way and package up sillycommercialpop with a Provides pop3-server and maybe a Conflicts pop3-server if you're feeling vindictive, and then you install the deb, or you never rely on Debian's automation again. When I recommend to people that they use kernel-package instead of DIY, they are usually a bit shocked.
Re: Re^2: strange behavior of dh_dhelp
On Tue, Sep 28, 1999 at 08:25:00PM +0100, Marco Budde wrote: ROTFL, why should I change dhelp to support a broken file format? ... dhelp supports all formats. ... These statements contradict each other. -- Raul
Re: mtools
On Wed, Sep 29, 1999 at 06:01:00PM +0200, Josip Rodin wrote: But who said mtools need to depend on floppyd package? $ dpkg -L mtools | grep floppyd /usr/bin/floppyd /usr/bin/floppyd_installtest /usr/share/man/man1/floppyd.1.gz -- Raul
Re: Can I have a package with no real name of upstream maintainer?
On Wed, Sep 29, 1999 at 10:08:39PM +0300, Antti-Juhani Kaijanaho wrote: Pseudonymes have been used throughout the history, so that's not a problem. For our protection, however, I'd recommend that you and tftp work out a agreement so that at least one Debian developer (you, for example) always knows who tftp is IRL, but he or she is forbidden to make this information public (or available to anyone else except when it is necessary to protect Debian from unfounded legal claims). PGP is legally classified in the same category as atomic weapons. [You know that the U.S. is in a state of emergency about this issue, and has been for a number of years, right?] -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote: the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that - our way is to encourage people to learn to do it for themself by not trying to hide the fact that knowledge and experience is required (not just optional or would be nice but absolutly required) the minimum hassle/inconvenience attitude? I agree. Sounds harmfull. When we ship a system with a bunch of stuff enabled by default, we're not only putting their machine at risk but we're also creating problems for everyone else who's system is attacked by someone using the debian machine as a jump-off point. That's bad. that's bad. it's also bullshit. enabling daemons by default is not inherently a security problem. And why can't there be an option to determine this? You avoided that point. Maybe you-know-better-than-I.. if they don't need it then they shouldn't install the package. And if the package has a dependency? There are many situations dealing with the package system that can lead to daemons installing without your knowledge. mtools for potato includes floppyd, if someone upgrades a slink machine to potato, should floppyd be automatically started? not all packages start daemons automatically. Some ask. Wouldn't it be keen if Joe Bloe knew what to expect? --francois
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 11:45:13PM -0500, Francois Gurin wrote: And why can't there be an option to determine this? You avoided that point. no i didn't. i answered it in another message. to paraphrase: i am against messing with the current default. i am not against (indeed, i am in favour of) increasing choice. if it is possible to add that choice without screwing anything up and without being a pain in the arse then i am all in favour of it. if they don't need it then they shouldn't install the package. And if the package has a dependency? There are many situations dealing with the package system that can lead to daemons installing without your knowledge. mtools for potato includes floppyd, if someone upgrades a slink machine to potato, should floppyd be automatically started? if mtools needs floppyd to run and the user has chosen to install mtools then yes. the user want mtools to work, they don't want mtools to work ONLY if they do some weird and obscure thing (even if it IS documented in the debian changelog, it is still weird and obscure unless they happen to be aware of the fact that this major change has occurred) which they never needed to do in the past... in other words, mtools used to just work, it should continue to just work after an upgrade. not all packages start daemons automatically. Some ask. Wouldn't it be keen if Joe Bloe knew what to expect? those that ask, shouldn't. there are already way too many stupid questions in postinst scripts. if (via debconf or whatever) there is a way for users to voluntarily specify that they want daemon packages to ask then that would be fine...but it should take some deliberate action on the user's part before they get these annoying questions. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 10:38:34PM -0400, Clint Adams wrote: read the rest of my message. the bit that ranted about unix's that get in the way of DIY. RH is one. sun's Netra is another...both are examples of how NOT to do configuration management on unix. No. You're talking about doing something your way and then having it wrecked by the RH/whatever way. And if you decide to do something your way in conflict with the Debian way, Debian may wreck your work too. debian provides methods of having your cake and eating it too. it provides tools for integrating your custom changes into the debian system so that you don't ever have to worry about the system screwing up your custom stuff. If I'm running /usr/local/sbin/sillycommercialpop3d, or /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck, and I want to install php72-pop3 which Requires pop3-server, this is what the dummy package (or whatever it is called is for). fake up as many Provides: lines as you need. and I naively apt-get install php72-pop3, not thinking it would require a local pop server or thinking that my pop server should be sufficient, if you suffer from this naivety then you need to cure it. expecting software to magically perform some miracle is not going to help you do anything but dig yourself into a much deeper hole. I'd probably end up with a nice little tagalog pop server that installs itself in inetd and steals the port. There are two simple solutions to this. this would be a problem caused by insufficient knowledge/experience on the part of the operator. don't fix the symptom, it'll just come back again...fix the cause instead. Either you do it the Debian way and package up sillycommercialpop with a Provides pop3-server yep, this is another good way of doing it. like the dummy package you get to DIY and still retain the benefits of the packaging system. if you don't like that, then there distributions which don't provide such useful system administration tools. try slackware, for example. When I recommend to people that they use kernel-package instead of DIY, they are usually a bit shocked. kernel-package is a useful tool which helps to DIY. it doesn't conflict with the notion of DIY at all, it makes it easier...especially if you like to compile your kernels on your fastest machine and then ship them out with scp to wherever they are needed. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders was heard to say: And if the package has a dependency? There are many situations dealing with the package system that can lead to daemons installing without your knowledge. mtools for potato includes floppyd, if someone upgrades a slink machine to potato, should floppyd be automatically started? if mtools needs floppyd to run and the user has chosen to install mtools then yes. the user want mtools to work, they don't want mtools to work ONLY if they do some weird and obscure thing (even if it IS documented in the debian changelog, it is still weird and obscure unless they happen to be aware of the fact that this major change has occurred) which they never needed to do in the past... in other words, mtools used to just work, it should continue to just work after an upgrade. I think it really looks like this question will not be solved until debconf is integrated into the distribution. floppyd is *not* required for mtools to work, it's just an optional and obscure 'feature' (not to mention either an evil or a clever hack :P) that most people aren't going to need (I wasn't even aware it existed until someone brought it up here) It also sounds like a potentially gaping security hole to me. In this case I think the only sane solution is to shut it off by default. I believe there are other packages that have similar situations (none spring to mind though) On the other hand, many things (like exim, ftp daemons, and inetd) should start running as soon as they're installed in most setups. (OTOH, a less promiscuous default inetd setup -- say, no ftp or telnet -- might be good) I don't really see any way to cleanly balance the needs of the four groups (two groups of packages, and two groups of users) without debconf. With debconf, it's laughably easy. Apologies if I have the idea of the system wrong :), but I think we just need to make a single template for all daemon entries, then specify the daemon name and the default setting (on or off) in each daemon. To keep people who aren't interested in this from having to see it, two things could be done. First, all the daemon-starting questions should have a higher priority than normal questions (I don't remember all the priorities now, but say maybe 2 above the 'total newbie' level). Second, an additional option could be collected by the base packages (at the same priority level) asking whether further daemon questions should be shown. (this might be a little trickier) Daniel -- Going on about Dungeons and Dragons being tools of the devil is like guarding the door while *it* is coming up through the floorboards... The Demon Lord of Hla'Siloth may want to cut your soul up into a thousand pieces, but at least he won't try to convince you that you haven't got one. -- [ approximately ] Terry Pratchett, _Johnny and the Dead_
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Mon, Sep 27, 1999 at 02:23:03PM +0200, Federico Di Gregorio wrote:
Scavenging the mail folder uncovered Siggy Brentrup's letter:
There should be one for the main distribution. Assume I want to go
into the CD business providing support for packages in the main
dist. No major problem with most of the packages, but I am not willing
to support packages with philosophical, political or religious
contents.
The way it is, I can't say Support for all of Debian's main dist.
My point is, should there be subjective stuff in the main dist?
I don't know the answer but having non-doc (in the sense of
non-application-that-is-in-main-doc) stuff is bad. What if I package
the 3 CD set of US maps that is publicy available? That is about 1.8Gb
of sources plus 1.8Gb of .debs for about 3.6Gb of ftp space... and
nobody can tell me don't do that!
OTH, everybody can say you to not do that. The only point where policy
say you not to do something, is about dfsg-freeness. Even there, they
just say you to put them in non-free. What protect Debian from abuse
is the eye-balls of everyone. The same ones who say: He! new-maintainer
take too much time! or What all those packages waiting so long in
Incoming? or even: Should we consider a free client of a non-free
server to be non-free?. I have a great confidence about hearing the
herd of kitten if you really upload the US maps, I'm just not sure
if they'll just say you to remove it or ask you to upload the more
recent version ;)
What about having Debian be an OS+apps and have SPI found a *new*
association for the distribution of free *data*? The data can even use
.deb format, but Debian/doc is definitely the wrong place for
religious/political/etc stuff. IMHO!
Why can't Debian just can't be this association? That's right that
main/doc is missed named and that we need a better sectionning
(main/graphics is even worst and what about x11). When I submit
data, I knew that it was just a patch, an incomplete solution to
the problem. It has to be easily realisable, implementable and not
too much contrainst so that it will add to Debian without removing
anything. IMHO, that's why it was accepted with so few discussions.
It was just a first step but now it's done. Debian will continue
to grow and we will handle it better then some company that forget
their starter consumers to go for the mass market. It's simply not
the way we work.
Debian is one of the most interesting example of distributed development
I can see. A very flat organization, based on volunteers, distributed
around the world and with a organizational system to make it shame most
of the RD directors of TOP500 companies. Sure, Debian don't follow
the same model but, that's ok: we don't even share the same goals; they
want to make money, we want to make the best distribution and have some
fun by doing so.
We have some fantastic tools: the build system, dpkg/apt, debconf/menu
consors, the cd-scripts, dinstall, the BTS, the vote system, the build
queue, the policy modifications process, etc. All this tools manage the
growth of Debian fantastically. There still some bugs to work around
(growing numbers of critical bugs, lag in the new maintainer process...)
but new initiatives (qa.debian.org and the sponsorship page) proves that
we aware about them and that we are in the process of correcting them.
Maybe should we make more publicity about this aspect of Debian. I'll
just give a conference next month about the organization of Debian,
what we are, how we work and how can they work *with* us. A quick
poll of people around me, all implicated in Linux just show me a big
point: most (something like half the people) think that Debian is a
startup company like RH was a time ago. They can't believe that Debian
work the same way as Linux, even a more open one should I say. Maybe
ESR should brainwash them a little more about the OpenSource model ;)
To everyone, keep working on this, I'm pretty sure we can get out
of it *without* removing anything to Debian. Just make it even
better!
Ciao,
Fabien
{ who finally remove his Debian patriotic hat ;) }
BTW, why couldn't we make a Cecilia/RoseGarden/abc contest for a
Debian Hymn? The FSF has one, why not us ;)
Ciao,
Federico
--
Federico Di Gregorio [http://www.bolinando.com/fog] {Friend of Penguins}
Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED]
Try the Joy of TeX [http://www.tug.org]
-- brought to you by One Line Spam
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Hosed potato/main/Packages...
Michael Alan Dorman [EMAIL PROTECTED] writes: the aleph-* packages have Priority: optionnal, which is, well, wrong. Yeah, just uploaded some new packages which fix the typo. Maybe it should be trapped by dinstall instead of hoosing apt/deselect/etc... Dpkg is happy with it however... Phil.
Re^4: strange behavior of dh_dhelp
Am 28.09.99 schrieb martin # internet-treff.uni-koeln.de ... Moin Martin! MB Marco localhost/doc/ should point to /usr/share/doc. Please submit a MB Marco bug report for your http daemon. MB The decision was made by the ctte, it is not yet implemented in the MB policy document, but it will be soon. Maybe somebody should email such documents to the maintainers of packages like dhelp. I#ve never received a copy of the decision. How should I support it? MB There is no requirement for Potato, that all packages support the MB latest policy. policy 2.4.x is still allowed. Great, really great. This will cause all kinds of problems. MB And these have the docs MB in /usr/doc. Ok, then Debian 2.2 will be broken. And the next releases will have the same problems, because we still allow policy 2.4 packages without any symlinks. So it won#t be possible to install Debian 2.2 and 2.3 packages on one system with a working documentation. MB With the decision on the /usr/doc - /usr/share/doc MB transition, every packages docs are accessable through MB /usr/doc/package. Wrong. Symlinks don#t work with http. MB What do you demand for the short time, until the revised policy is MB released? All packages using the symlink have to remove him? Lintian MB must not report a missing symlink? Debhelper has to cease installing MB this link? If you ask me: (1) All packages of Debian 2.2 must use /usr/share/doc. Otherwise we will have the same problems in Debian 2.3, when the user reads the documentation via /usr/share/doc. (2) All packages provides /usr/doc links. (3) http://localhost/doc/ points to /usr/share/doc, the user use /usr/share/doc instead of /usr/doc. This is a clean solution and not such a hack like the descripted decision. MB My god, Marco, show some reason. (a) symlinks don#t work with the http protocol (b) old policy allowed - problems in Debian 2.3. ... cu, Marco -- Linux HOWTOs - Die besten Loesungen der Linuxgemeinde ISBN 3-8266-0498-9 Uni: [EMAIL PROTECTED] Fido: 2:240/6298.5 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/
Re: Is XEmacs nonfree?
On Thu, 30 Sep 1999, Marcus Brinkmann wrote: The FSF does only include code in GNU programs if the author assigns the copyright to the FSF by signing a paper. Wrong. Take a look at http://www.gnu.org/software/ At least shtool and WindowMaker are copyrighted by their authors. Denis
Re: a question about BTS severities
On Tue, Sep 28, 1999 at 12:01:16PM +1000, Herbert Xu wrote:
On Mon, Sep 27, 1999 at 05:30:51PM -0700, Joey Hess wrote:
Actually, it should be critical if it's a root exploit. Grave only
includes
those that only comprise the user's account.
Last I checked, root is a user. This is not a formal definition we're
working from, please use common sense. (Note: grave is a _higher_ priotity
than critical. Note also: root exploits tend to turn into user account
exploits as soon as the attacker wants them to.)
Root may be a user, but he is a special one at that :) root has privileges
that no other users have. If a user account was compromised, the attacker
is only able to perform tasks that user was allowed to, however, if the
root account is compromised, then that implies the compromise of all user
accounts on that machine, and things like using privileged ports, or
doing port IO, etc.
I think that any user account exploit is critical - maybe it's a sudoers,
not. However, grave is for exploit such as external access to private file
without however giving login access to the machine.
Also, AFAIK, critical is listed above grave (and important and others) in
all the relevant docos that I've seen.
That's what I read also.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Re^4: strange behavior of dh_dhelp
Marco Budde wrote: (a) symlinks don#t work with the http protocol You know, I've read the http protocol, and I don't recal any mention of such unix-centric concepts of symlinks, especially not any prohibition of them. If you're going to keep insisting the http protocol doesn't support symlinks, please quite me chapter and verse from RFC 2068. -- see shy jo
Re: Is XEmacs nonfree?
There are two things: - copyright (who owns it?) - licence (what can I do with it?) Debian is only concerned with the second point. On Thursday 30 September 1999, at 0 h 54, the keyboard of David Coe [EMAIL PROTECTED] wrote: But in another sense it is not GNU software, because we can't use XEmacs in the GNU system: using it would mean paying a price in terms of our ability to enforce the GPL. It is very ancient rms' opinion: the FSF asks you to yield the copyright to them, because they fear the GPL is not a sufficient warranty, before a court. They think that, if someone keeps the copyright, he could switch a GPL software to proprietary. In essence, it means you should blindly trust the FSF instead of blindly trusting Linus Torvalds or any other copyright holder. For the man page of emacsclient (less than a page in print!), I had to send a signed paper document to the FSF giving up my copyright :-( (BTW, in France, and in most European countries, this will not be accepted.) Apart from rms, everybody thinks that a program can be GPL even if the copyright does not belong to the FSF. The Linux kernel, for instance, whose copyright is from its many contributors. worked on XEmacs have not provided, and have not asked other contributors to provide, the legal papers to help us enforce the GPL. Pure FUD.
Can't acces db.debian.org
Ciao *,
apparently I can't access db.debian.org: I use my password
on master and the server gives me authentication failed. (Note that
I can login in master with that same password.) Is something broken?
(my brain for example?)
Ciao,
Federico
--
Federico Di Gregorio [http://www.bolinando.com/fog] {Friend of Penguins}
Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED]
Try the Joy of TeX [http://www.tug.org]
-- brought to you by One Line Spam
Re: Is XEmacs nonfree?
[EMAIL PROTECTED] writes: On Thu, 30 Sep 1999, Marcus Brinkmann wrote: The FSF does only include code in GNU programs if the author assigns the copyright to the FSF by signing a paper. Wrong. indeed. Even in the FSF's Emacs 20.4 there are parts which are: Copyright (C) 1995, 1997 Electrotechnical Laboratory, JAPAN. Licensed to the Free Software Foundation. Gunnar
Problem with the latest potato update
Hi, Latest potato update contains a package, aleph-dev, with a wrong Priority: line which prevents (until manually fixed) the apt update operation, which aborts with: E: Malformed Priority line E: Error occured while processing aleph-dev (NewVersion1) The Priority: line is Priority: optionnal instead of Priority: optional greetings, marek pgpXseTsJbeKt.pgp Description: PGP signature
Re: strange behavior of dh_dhelp
Marco Budde [EMAIL PROTECTED] wrote: Ok, then Debian 2.2 will be broken. No. There are not many packages which quickly switched to /usr/share/doc without the symlinks. The maintainers of these packages quickly changed, so they are alive and the should be able to add the symlink to their next versions of the packages as quickly as they uploaded before. So why should 2.2 be broken? Potato _is_ broken at the moment, but this can be fixed. And the next releases will have the same problems, because we still allow policy 2.4 packages without any symlinks. The next (potato+1) requires all documentation in /usr/share/doc _and_ Symlinks in /usr/doc. So it won#t be possible to install Debian 2.2 and 2.3 packages on one system with a working documentation. So there is no problem with 2.2+2.3. Then 2.4 will remove the symlinks but now all packages from 2.3 placed their docs in /usr/share/doc, so you can use packages from 2.3+2.4 together with all docs in /usr/share/docs. Wrong. Symlinks don#t work with http. What does the HTTP protocol have to do with the Unix file system? It depends on the HTTP server, whether it follows symlinks or not. Apache handles this without problems for ages and FollowSymlinks is activated in the default configuration for /usr/doc. I think that other HTTP servers will do the same, and if one doesn't do so, it's more likely that they support to follow symlinks instead of _not_ to follow symlinks. BTW: I think that it is a bug, if an HTTP server isn't configurable in this case. And don't forget that we already have many symlinks in /usr/doc for ages, which are explicitly allowed by policy: /usr/share/doc/package-name may be a symbolic link to a directory in /usr/share/doc only if two packages both come from the same source and the first package has a Depends relationship on the second. These rules are important because copyrights must be extractable by mechanical means. If you ask me: (1) All packages of Debian 2.2 must use /usr/share/doc. Then the release date of 2.2 will be at the end of 2000 or later. That's simply unrealistic. If you personally want to upload 2000 NMUs (for each architecture!), this may be able sooner, but Otherwise we will have the same problems in Debian 2.3, when the user reads the documentation via /usr/share/doc. No. Read the time table above or in one of my last mails. (2) All packages provides /usr/doc links. That's right for 2.2 and 2.3. (3) http://localhost/doc/ points to /usr/share/doc, the user use /usr/share/doc instead of /usr/doc. That's wrong. http://localhost/doc/ points to /usr/doc in 2.2 and 2.3. This will change in 2.4. This is a clean solution It is clean if all Debian maintainers update all their packages in all architectures and if every user upgrades the complete system from 2.1 to 2.2 and not only parts. If you cannot be sure that these requirements are resolved, it is not clean. and not such a hack like the descripted decision. Yes, the decision is a hack. But it works and offers a smooth transition. We have to release potato soon (slink is very old and our users want a new release, otherwise the may use a different distribution) and potato should be as consistent as possible. The hack gives us a consistent potato (all doc available via /usr/doc), your proposal does not. Anyway, the decision was made, like it or hate it but stop discussing it again and again. This doesn't help and won't change anything. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote: sorry, it's you who needs to wake up to the real world. if people don't know how to administer a unix machine then they need to learn fast. Not true. Maintaining a unix-like machine for desktop or personal use requires a different skill set than a machine used as a server. People using linux as a windows replacement or because they want to see what linux is *don't need* a bunch of services enabled *by default*. And if there is no way to access the machine remotely then there's no harm if having a non-guru administer the machine. (It can be a security nightmare, but if no one can get in, it doesn't matter.) no amount of molly-coddling by the distribution authors (i.e. us) is going to obviate that essential requirement. maintaining security on your own systems requires personal knowledge and experience, it can not be done by proxy. Agreed, for machines that need public services. But I'm talking about defaults. Can you come up with a reason we *need* a bunch of stuff enabled by default? the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that This is empty we're better than them propaganda. Debian already makes choices in what services are installed and enabled by default. It does not follow that changing the *existing* list of services we enable by default implies a we-know-better-than-you attitude. (OTOH, saying if you want to disable the service, remove the package--there's no reason to do anything else does seem to imply such an attitude.) When we ship a system with a bunch of stuff enabled by default, we're not only putting their machine at risk but we're also creating problems for everyone else who's system is attacked by someone using the debian machine as a jump-off point. That's bad. that's bad. it's also bullshit. enabling daemons by default is not inherently a security problem. A system with daemons disabled will always have a better guarantee of security than one with daemons enabled. In the not-so-distant past we've shipped systems with a vulnerable telnetd and a vulnerable ftpd enabled *by default.* If they'd been off instead of on they wouldn't have been a security problem for the many people who never used them. see previous message. if a particular daemon is a problem then it needs to be fixed or replaced or dropped from the distribution. changing the default so that it is only enabled manually will NOT increase security at all. See above. It's really time to get away from the mentality that everyone needs to have everything turned on all of the time; if a persone really *needs* something enabled, they can figure out how to do it. (If they can't, should they really be administering a network node?) if they don't need it then they shouldn't install the package. It's a default. Not everyone reads everything about every package--that's just the way things are, and we need to work with that in mind rather than building this wall of fantasy that we can do dangerous things as long as we bury a disclaimer in the docs. *That's* the commercial vendor's mentality you lamented previously. why run debian (with all it's useful tools like update-inetd and update-rc.d and so on) if you're going to throw away those advantages? Why does changing default behavior throw away advantages? What prevents you from using those tools if you want them? it's damned annoying to see people trying to force their personal preferences on everyone else by making loud noises about trumped up nebulous and vague security issues. it would be nicer if such FUD were left behind in the proprietary software world. What reasoning are you providing other than personal preference? Do you have any critique other than a misguided that's what they do in the big bad proprietary software world? (FYI, enabling everything by default is exactly what they do in the proprietary world because they don't have the courage to change things. Some vendors still have passwordless accounts because they're afraid to change things. I expect better from free software--we've always done it this way is not adequate defense.) Mike Stone pgpUnuT0MvfHV.pgp Description: PGP signature
Problem with the latest potato update
Marek Habersack writes: Hi, Latest potato update contains a package, aleph-dev, with a wrong Priority: line which prevents (until manually fixed) the apt update operation, which aborts with: E: Malformed Priority line E: Error occured while processing aleph-dev (NewVersion1) The Priority: line is Priority: optionnal instead of Priority: optional File a critical bug, if no-one has yet done so. Matthew -- At least you know where you are with Microsoft. True. I just wish I'd brought a paddle. http://www.debian.org/
Re: Problem with the latest potato update
Matthew Vernon [EMAIL PROTECTED] writes: Latest potato update contains a package, aleph-dev, with a wrong Priority: line which prevents (until manually fixed) the apt update operation, which aborts with: File a critical bug, if no-one has yet done so. There has been filed enough bugs against this problem. And a new aleph packages is waiting in incoming. -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, The Dead Past
corel linux demo
I got a chance to see a demo of Corel's linux at the Miami Comdex yesterday. They have done a very good job of putting this together and from the looks of this Bill has good reason to fear loosing the desktop! They didn't demo their installer, but were bragging that it would install Linux in under 6 minutes on the average PC. They did a good job of intergrating Linuxconf into debian, and their graphical front end around apt looks great. I hope this piece of code is GPL'ed, and that debian will steal (borrow) from it. They have made some improvements to the KDE desktop, some of which look rather gnomeish. They plan to port their Wordperfect office suite to Linux via wine, which implies that they are doing some heavyweight work on Wine. This probably means that MS office will also end up on many linux desktops though! They said that the beta of their linux distro will be available for public download by the end of October. I hope some shovelware cd makers will burn their beta onto cdr and sell it for those of us without T1 lines. If they put it up as an ISO image I will try to grab the file from the office on an overnight download. Oh BTW they were also giving away copies of Wordperfect for linux, personal edition (CD only). Wordperfect is the only app they have ported as a Native linux binary, and after version 8, they probably won't be doing a linux native binary version. So WP version 9 will be a win32 binary under Wine. = Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
Re: Hosed potato/main/Packages...
Philippe Troin [EMAIL PROTECTED] writes: Yeah, just uploaded some new packages which fix the typo. I just hand-edited my available file. :-) Maybe it should be trapped by dinstall I tend to agree. I wonder how that can be done using the tools themselves, so we don't end up with implementations that differ. Mike.
Re: Problem with the latest potato update
On Thu, 30 Sep 1999, Matthew Vernon wrote: E: Malformed Priority line E: Error occured while processing aleph-dev (NewVersion1) The Priority: line is Priority: optionnal instead of Priority: optional File a critical bug, if no-one has yet done so. Against what? aleph? Okay, one bug against aleph, but IMHO an at least important bug should be filed against dinstall for not rejecting the package and thus letting it to screw the Packages file. greetings endre -- ..all in all it's just another rule in the firewall. /Ping Flood/
Re: Can I have a package with no real name of upstream maintainer?
On Thu, Sep 30, 1999 at 08:46:38AM +0300, Antti-Juhani Kaijanaho wrote: On Wed, Sep 29, 1999 at 10:56:53PM -0400, Raul Miller wrote: PGP is legally classified in the same category as atomic weapons. No, it's not. Atomic weapons are controlled by international treaties, and AFAIK it would be a serious offence for me - or any other Finn - to have some in my possession [Scandinavia is a nuke-free zone, IIRC]. PGP is not regulated in Finland (except by ordinary copyright issues). Treaties are different from laws. But you're right, I should have ended that sentence with the clause in the U.S. -- Raul
Re: Is XEmacs nonfree?
On Thu, Sep 30, 1999 at 10:10:54AM +0200, Stephane Bortzmeyer wrote: It is very ancient rms' opinion: the FSF asks you to yield the copyright to them, because they fear the GPL is not a sufficient warranty, before a court. No, they just know that only the copyright owner can sue for copyright infingement. They want to be able to defend GNU code in court, and that means that they must be able to sue, which means they must own the copyright. It is also possible to sign a copyright disclaimer, effectively putting the code in the public domain; this is acceptable for GNU code. They think that, if someone keeps the copyright, he could switch a GPL software to proprietary. No they don't. The FSF copyright transfer gives (IIRC) the author a unrestricted and unrevocable license to the code. In essence, it means you should blindly trust the FSF The FSF copyright assignment papers restrict FSF so that they can only license the code as free software. In any case, this is not a case of trust. For the man page of emacsclient (less than a page in print!), I had to send a signed paper document to the FSF giving up my copyright :-( (BTW, in France, and in most European countries, this will not be accepted.) Can you elaborate on that? Why is the FSF copyright transfer invalid in Europe? (AFAIK, although IANAL, copyright transfer is a valid procedure everywhere.) Apart from rms, everybody thinks that a program can be GPL even if the copyright does not belong to the FSF. The Linux kernel, for instance, whose copyright is from its many contributors. The problem is not whether something can be GPL even though FSF didn't own the copyright. In fact, the GNU project *encourages* people to use GPL in their own programs, and does not even suggest a copyright transfer to FSF. Please stop spreading FUD like this. worked on XEmacs have not provided, and have not asked other contributors to provide, the legal papers to help us enforce the GPL. Pure FUD. No it isn't. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: corel linux demo
On Thu, Sep 30, 1999 at 05:29:29AM -0700, Kenneth Scharf was heard to say: They said that the beta of their linux distro will be available for public download by the end of October. Hm. Do you have any information about the following issues: - How big is it? The only spare partition I could try this out on is an old swap partition (currently used for Hurd, but I don't have time to fiddle with that at the moment..). If corel is going to shovel tons of stuff (eg, X and KDE) onto my disk, I doubt I can even try it. - How 'nice' is it? If it's a 6 minute install, I doubt it really gives you options about what to do. I don't need it clobbering my Windows installation -- or, worse, my current Linux installation! More annoying would be if it decided that it was going to install LILO for me (I use GRUB to boot) I'd like to at least take a look at this and see what they fixed (I seem to remember hearing that they eliminated the horrible flat organization we use for packages and put in some sort of logical hierarchy) but I can't conjure up disk space or risk my current installations.. Oh BTW they were also giving away copies of Wordperfect for linux, personal edition (CD only). Wordperfect is the only app they have ported as a Native linux binary, and after version 8, they probably won't be doing a linux native binary version. So WP version 9 will be a win32 binary under Wine. Are you sure? Wine is not only a binary-compatibility system; it also aims for source-compatibility. They might just be using the Windows version as the canonical source. Daniel -- You have the right to remain silent. Anything you say will be misquoted, then used against you.
[Fwd: corel linux demo]
Why wait for a third party to make disks, Corel will be making disks for the next beta and the final version. For more information, see http://linux.corel.com Original Message Subject: corel linux demo Resent-Date: 30 Sep 1999 12:28:33 - Resent-From: debian-devel@lists.debian.org Resent-CC: recipient list not shown: ; Date: Thu, 30 Sep 1999 05:29:29 -0700 (PDT) From: Kenneth Scharf [EMAIL PROTECTED] To: debian-devel@lists.debian.org They said that the beta of their linux distro will be available for public download by the end of October. I hope some shovelware cd makers will burn their beta onto cdr and sell it for those of us without T1 lines. If they put it up as an ISO image I will try to grab the file from the office on an overnight download.
First beta version of the Debian SGML/XML HOWTO
Since it seems a lot of people have trouble with SGML, since there is irony very few documentation/irony about a language which is supposed to ease the job of documenting, since FAQ are... frequent on this topic, I just wrote the Debian SGML/XML HOWTO. The emphasis is on practical information: how to type and how to process SGML files. It is Debian-specific and intended that way: for any other Unix, I would have to double its size, just for compilation and installation instructions. http://www.debian.org/~bortz/SGML-HOWTO/ You are welcome to send patches, speling fixes, request for improvments or additions.
Re: Packages should not Conflict on the basis of duplicate functionality
There is currently no default -- it varies on a per-package basis. I note that ### to run vtund as a server on port 5000, uncomment the following line: #--server-- 5000 isn't uncommented by default.
Re: Hosed potato/main/Packages...
On 30 Sep 1999, Michael Alan Dorman wrote: Philippe Troin [EMAIL PROTECTED] writes: Yeah, just uploaded some new packages which fix the typo. I just hand-edited my available file. :-) Maybe it should be trapped by dinstall I tend to agree. I wonder how that can be done using the tools themselves, so we don't end up with implementations that differ. If the installing programs go belly up because of typos in individual packages, it is the responsibility of the build program to validate those critical fields. Validating the control file (like the changelog is validated during the source build) before the build is the right place to do this. On the other hand, it could be argured that dselect and apt should not fail so miserably over a single package with a minor flaw. (There should be some fairly simple recoverey logic for these error cases...like mark the package a broken and go on with those parts of the install that don't depend on that particular package) In slink, if you include dhttp in the install, without first installing the packages that dhttp pre-depends upon, dselect will roll over and play dead before it tries to install any packages. It should probably just mark dhttp as a failed attempt, and go on with the rest of the packages. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: corel linux demo
--- Daniel Burrows [EMAIL PROTECTED] wrote: On Thu, Sep 30, 1999 at 05:29:29AM -0700, Kenneth Scharf was heard to say: They said that the beta of their linux distro will be available for public download by the end of October. Hm. Do you have any information about the following issues: - How big is it? The only spare partition I could try this out on is an old swap partition (currently used for Hurd, but I don't have time to fiddle with that at the moment..). If corel is going to shovel tons of stuff (eg, X and KDE) onto my disk, I doubt I can even try it. - How 'nice' is it? If it's a 6 minute install, I doubt it really gives you options about what to do. I don't need it clobbering my Windows installation -- or, worse, my current Linux installation! More annoying would be if it decided that it was going to install LILO for me (I use GRUB to boot) I would guess that it's at least as big as a minimal install of Mandrake. They won't be including as many aps as debian has, they will probably 'farm' the debian selection for the most popular ones. Also they mentioned that their install process is to install first and configure later. This means that the user does not need to worry about things like network addresses when first getting the os on the computer. Only once linux is up and running and you can actually log in do you set up networking, mail and such. (Of course if you are installing OVER a network in an enterprise setup this changes things a litte) I'd like to at least take a look at this and see what they fixed (I seem to remember hearing that they eliminated the horrible flat organization we use for packages and put in some sort of logical hierarchy) but I can't conjure up disk space or risk my current installations.. They did mention that their installer understood package hierarchy but I only saw a static snapshot of a current install of packages. They did not demo the actual install of any packages. However the display did look better than glint or gnorpm, with a better user interface. It also looked much better than dselect (but then again dselect is rather long in the tooth.) Oh BTW they were also giving away copies of Wordperfect for linux, personal edition (CD only). Wordperfect is the only app they have ported as a Native linux binary, and after version 8, they probably won't be doing a linux native binary version. So WP version 9 will be a win32 binary under Wine. Are you sure? Wine is not only a binary-compatibility system; it also aims for source-compatibility. They might just be using the Windows version as the canonical source. I understood wine as being a library that intercepted win32 calls and redirected those calls into the correct X or linux libraries for handling. Corel intends (as I understand it) to ship the actual windows binaries (.exes) and maybe even .dll's with whatever wrappers are required to run them under Wine. There will probably even be a Wine based program launcher that will trigger of an icon for the installed program on the desktop or 'K bar'. Wine's ultimate result is to make the win32 API become a linux api as well. It would stand beside gtk++ and QT in that regard. Also means that the setup.exe program that is used by all windows apps to install the thing would run under wine as well, only there would NOT be a real windows partition on your filesystem (though there would have to be a file system or directory pointed to by the wine.conf file to take it's place). Maybe I'm wrong about some of these points but's that's how I interperted it. = Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
Re: Packages should not Conflict on the basis of duplicate functionality
There is currently no default -- it varies on a per-package basis. On Thu, Sep 30, 1999 at 09:21:29AM -0400, Clint Adams wrote: I note that ### to run vtund as a server on port 5000, uncomment the following line: #--server-- 5000 isn't uncommented by default. Sure, but in the context of daemon processes that's not the one default: that's just one of many many. Are you saying you don't ever want any packages to change their default? [Sounds rather draconian to me.] Are you saying that there's some kind of debian default which you're trying to preserve? [If so, what is it? ... note that if this default is reasonable behavior then the definition of that default is almost always what we're discussing.] Or are you saying something else? -- Raul
i18n document and CVS
Hi, I wrote version 5 of the draft of the document on i18n. It is available at http://surfchem0.riken.go.jp/~kubota/linuxwork/i18ndoc.html. Now I rewrote it in SGML (DebianDoc). I will not change format any more. Contributions are welcome. Without contributions, this document would be a document on Japanization, not on i18n! I hope that this document is controlled under CVS of DDP, because it makes contributions easier. Then I'd like to have a writing account for that CVS. Though I sent an application mail to new-maintainers, I am not a member of Debian yet. Can I still have a writing account for the CVS? If not, is there any other similar solution? --- Tomohiro KUBOTA [EMAIL PROTECTED]
Re: Packages should not Conflict on the basis of duplicate functionality
Or are you saying something else? I was merely pointing out the irony of one of Craig's packages not enabling the daemon by default.
Re: Can I have a package with no real name of upstream maintainer?
On Thu, Sep 30, 1999 at 08:50:40AM -0400, Raul Miller wrote: Treaties are different from laws. On the contrary, ratified treaties are a binding part of the Finnish legislation, as if they were ordinary laws passed by the parliament. (IIRC) This may be different in the common law (sp?) system used in USA, though. IANAL, of course. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Problem with the latest potato update
On 30-Sep-99, 07:50 (CDT), Hirling Endre [EMAIL PROTECTED] wrote: On Thu, 30 Sep 1999, Matthew Vernon wrote: E: Malformed Priority line E: Error occured while processing aleph-dev (NewVersion1) The Priority: line is Priority: optionnal instead of Priority: optional File a critical bug, if no-one has yet done so. Against what? aleph? Okay, one bug against aleph, but IMHO an at least important bug should be filed against dinstall for not rejecting the package and thus letting it to screw the Packages file. And another against apt for allowing a trivial bug affecting one package to completely break it (if, in fact, it does -- I haven't tried it). It should just ignore the affected package(s). Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Can't acces db.debian.org
On Thu, 30 Sep 1999, Federico Di Gregorio wrote: apparently I can't access db.debian.org: I use my password on master and the server gives me authentication failed. (Note that I can login in master with that same password.) Is something broken? (my brain for example?) You probably changed your password since it was copied over. Use this command: echo Please change my Debian password | gpg --clearsign | mail [EMAIL PROTECTED] And you will get a new password mailed back. (pgp -fast instead of gpg if you are not using gpg yet) Jason
Re: Can I have a package with no real name of upstream maintainer?
On Thu, Sep 30, 1999 at 07:23:53PM +0300, Antti-Juhani Kaijanaho wrote: On Thu, Sep 30, 1999 at 08:50:40AM -0400, Raul Miller wrote: Treaties are different from laws. On the contrary, ratified treaties are a binding part of the Finnish legislation, as if they were ordinary laws passed by the parliament. (IIRC) This may be different in the common law (sp?) system used in USA, though. IANAL, of course. Well, technically, there are no laws against encryption in the U.S.A. There are laws against exporting munitions. There's a regulation which classifies encryption as munitions (in the same category as atomic weapons). It's probably true that this executive decision doesn't have much bearing on treaty negotiations. Then again, treaty restrictions on the use of atomic weapons don't do anything to prevent the U.S. government from classifying encryption in the same fashion as atomic weaponry for the purposes what's legal to export from the U.S. The U.S.'s first ammendment does prohibit at least some of the current restrictions, but for the most part no one with enough authority to do much about this really cares. -- Raul
ITR: intent to rename poc to objc
Hi, I am going to rename the poc (portable object compiler) package to objc if no-one objects. The upstream author requested this. Also, libgc4 (boehm gc) support is dropped. A new additional package will be introduced with libgc5 support. Cheers, Marcel Please send a Cc to me when replying to me on this mailinglist. pgpGIBdvKmXPe.pgp Description: PGP signature
Re: ITR: intent to rename poc to objc
On Thu, Sep 30, 1999 at 09:05:43PM +0200, Marcel Harkema wrote: I am going to rename the poc (portable object compiler) package to objc if no-one objects. The upstream author requested this. Also, libgc4 (boehm gc) support is dropped. A new additional package will be introduced with libgc5 support. Does this mean that this compiler can deal with objective C? [Note: this isn't an objection, but if you do this and they're not the same thing you'll need to deal with the confusion somehow.] -- Raul
Re: Hosed potato/main/Packages...
Dale Scheetz [EMAIL PROTECTED] writes: On 30 Sep 1999, Michael Alan Dorman wrote: Philippe Troin [EMAIL PROTECTED] writes: Yeah, just uploaded some new packages which fix the typo. I just hand-edited my available file. :-) Maybe it should be trapped by dinstall I tend to agree. I wonder how that can be done using the tools themselves, so we don't end up with implementations that differ. If the installing programs go belly up because of typos in individual packages, it is the responsibility of the build program to validate those [ etc. etc. ...] Okay, people are over-reacting a little here. It's not a bug in the package, it's a bug in me. I added `optionnal' to the override file (carelessly cut'n'waste from the package). The override file is what matters, not the package (that is, after all, why it's there... to override). Yes, dinstall probably should validate the priority field. However, the build tools should not. Apt should definitely not die on invalid priorities, and indeed, Jason has already fixed it not to and it won't do so in future versions. Dselect, AFAIK, doesn't die, nor does dpkg. This breakage, was fixed within hours of being first reported (at least on master, propagation not included), and only affects apt weanies^H^H^H^H^Husers [;)]. The End. (I hope?) -- James
Re: ITR: intent to rename poc to objc
Raul Miller wrote: On Thu, Sep 30, 1999 at 09:05:43PM +0200, Marcel Harkema wrote: I am going to rename the poc (portable object compiler) package to objc if no-one objects. The upstream author requested this. Also, libgc4 (boehm gc) support is dropped. A new additional package will be introduced with libgc5 support. Does this mean that this compiler can deal with objective C? [Note: this isn't an objection, but if you do this and they're not the same thing you'll need to deal with the confusion somehow.] The POC handles Objective-C by translating it to C++, IIRC. -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.ddns.org is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.org/~deek/
{R,I[INEW]}TP: free ssh [non-US]
Hi, OpenBSD have started working on the last free SSH (1.2.12 was under a DFSG free license AFAICT[1]), they also, (again AFAICT [I'm going by the CVS commits]), are ripping out the patented algrothims (IDEA, etc.). Unfortunately, I'm chronically busy with work and haven't had time to look into it, but all the signs look very good (they appear to have added it as part of their base system, for example). So, I tentatively announce a preliminary ITP, pending confirming that their hacked version is indeed DSFG free. _But_, I'd much rather someone with more free time would do it instead. So, please, someone else (who doesn't live in the USA) have a look/go... Source is, of course, available from OpenBSD. CVS or FTP, see www.openbsd.org for a mirror near you. [Yes, I know about lsh, but from what I've heard from people who track it, it's not ready for prime time.] -- James [1] Please, don't bring up the red herring of that being v. old and that there have been security fixes... this is OpenBSD, they've fixed/are fixing them :)
Re: warning: lilo 22dev0-1 can make your system unbootable !
Vincent == Vincent Renardias [EMAIL PROTECTED] writes: Vincent short summary: lilo v22 works only with 2.0 kernels; it Vincent won't boot a 2.2.x or a 2.3.y. a v21 version has been Vincent reuploaded to master this morning. Hmmm, sure? $ dpkg -l lilo ii lilo22dev0-1 LInux LOader - The Classic OS loader can loa $ uname -a Linux pooh 2.2.12 #1 Mon Sep 27 14:53:51 PDT 1999 i686 unknown $ uptime 10:53pm up 1:33, 2 users, load average: 0.00, 0.02, 0.00 Or is this just a disaster waiting to happen? -- Stephen --- If 8-year-old boys discharging loaded firearms into their own legs isn't necessary to the maintenance of a well-regulated militia, I don't know what is. - Randal Cummings as reported in The Onion, 25/5/99
Re: corel linux demo
Wordperfect is the only app they have ported as a Native linux binary, and after version 8, they probably won't be doing a linux native binary version. So WP version 9 will be a win32 binary under Wine. Are you sure? Wine is not only a binary-compatibility system; it also aims for source-compatibility. They might just be using the Windows version as the canonical source. What Corel are working on is WineLib - which acts as the source-compatible version of Windows. It will allow Corel to compile their Windows applications on Linux with minimal #ifdef'ing, and produce a native Linux application. There won't be wrapper scripts or any such things, it will come statically linked to WineLib (which is allowed because the Wine License is similar to the BSD license).
Re: A simple question about unstable
On Wed, Sep 29, 1999 at 04:11:08PM -0400, Bill White wrote: I hope this is not a foolish question. I have looked at the FAQ and the Debian web page, but I haven't found the answer. I, too, was faced with this not too long ago. It's not a difficult fix but it's not obvious. What's the best way to get a current copy of unstable for installation on a single, not-very-well-connected machine? [...] Is it possible to upgrade from slink to potato using a 56k modem connection? If it takes 650Mb to upgrade everything it is not possible. If it is, my problems are solved, of course. It's possible, of course. It's possible to upgrade with a 2400 baud modem, but I wouldn't want to do it. :) What's involved: Change your /etc/apt/sources.list file. This is mine: # Use for a local mirror - remove the ftp1 http lines for the bits # your mirror contains. # deb file:/your/mirror/here/debian stable main contrib non-free # See sources.list(5) for more information, especial # Remember that you can only use http, ftp or file URIs deb http://http.us.debian.org/debian unstable main contrib non-free deb-src http://http.us.debian.org/debian unstable main contrib non-free deb http://non-us.debian.org/debian-non-US unstable non-US/main non-US/contrib non-US/non-free The deb-src is optional. (Provides apt-get source packagename functionality) Now apt-get update, and then apt-get dist-upgrade . It shouldn't be much more than 100, 150 megs - an overnight should do it (hoping of course that you aren't charged per minute for calls). Important to realise is that, while slink comprises 2 CDs, you don't have all the packages installed. (I hope you don't!) Therefore apt will only upgrade what you need.
Re: warning: lilo 22dev0-1 can make your system unbootable !
On Wed, Sep 29, 1999 at 10:54:32PM -0700, Stephen Zander wrote: $ dpkg -l lilo ii lilo22dev0-1 LInux LOader - The Classic OS loader can loa $ uname -a Linux pooh 2.2.12 #1 Mon Sep 27 14:53:51 PDT 1999 i686 unknown $ uptime 10:53pm up 1:33, 2 users, load average: 0.00, 0.02, 0.00 Did you /run/ lilo, too? Or just installed it? Thomas -- GnuPG: ID=B0FA4F49, http://www.in.tum.de/~schoepf/gpgkey.txt Fingerprint: FA38 2D7E 408F 61E4 BF49 B48F 04BD F5BE B0FA 4F49 PGP 2: ID=2EA7BBBD, http://www.in.tum.de/~schoepf/pgpkey.txt Fingerprint: 08 96 1F CD AD 55 03 0F 95 92 B0 F2 04 32 4B 52 pgpOuOZMyIkr6.pgp Description: PGP signature
BTS: How are the bug reports organized?
I'm currently working on a tool that automatically fetches all bug reports belonging to one package. The base url is http://www.debian.org/Bugs/db/ and I always thought that the subdirectories were designed so that only up to 999 files go into a single directory. But today, I noticed that this assumption seems to be wrong when trying to download the page for e.g. Bug#8429. It's not in /8/ but /84/. So, the directory is only determined by the leading 2 digits? If so, what will happen when our bugs reach 6 digit numbers (Currently, the number of bug reports seems to grow exponentially...). Putting 1-1 files into a single directory doesn't sound very wise to me... Thomas -- GnuPG: ID=B0FA4F49, http://www.in.tum.de/~schoepf/gpgkey.txt Fingerprint: FA38 2D7E 408F 61E4 BF49 B48F 04BD F5BE B0FA 4F49 PGP 2: ID=2EA7BBBD, http://www.in.tum.de/~schoepf/pgpkey.txt Fingerprint: 08 96 1F CD AD 55 03 0F 95 92 B0 F2 04 32 4B 52 pgph6PmJ8h8yQ.pgp Description: PGP signature
Re: warning: lilo 22dev0-1 can make your system unbootable !
Thomas == Thomas Schoepf [EMAIL PROTECTED] writes: Thomas Did you /run/ lilo, too? Or just installed it? Yep, the postinst automatically reruns lilo assuming you take the default answers to all the questions it asks. -- Stephen --- If 8-year-old boys discharging loaded firearms into their own legs isn't necessary to the maintenance of a well-regulated militia, I don't know what is. - Randal Cummings as reported in The Onion, 25/5/99
