RE: [RFC] Would there be a need for a java-wrappers package?
From: Igor Pechtchanski I would like to hear opinions on how useful a java-wrappers package would be. The package will contain a few shell scripts that allow users to invoke the regular Java SDK tools (java, javac, javadoc) from Cygwin, making them look like their Unix counterparts (i.e., POSIX filenames). The scripts would be updated versions of those posted in http://cygwin.com/ml/cygwin/2003-01/msg00174.html. There are a few reasons why I have misgivings about this. First off, some tools (notably Ant and Tomcat) recognize Cygwin and do something specific to Cygwin anyway, which will probably (most likely) get screwed up if the java they find looks like a Unix version (this did happen to me with Ant and Cygwin-native jikes). Secondly, the tools will certainly not be foolproof (although I'll try my best to make them as robust and autonomous as possible). Thirdly, java versioning may become a problem. Igor, I'd be interested and have had some fixes committed to Ant before so I know folks there, if you want to continue this off-list, please feel free to email me directly (I almost posted to your private address, but thought an invitation to chat would go down better ;) J.
Re: i'd like to submit dictd into cygwin
On Sun, Feb 22, 2004 at 10:27:17AM +0100, Gerrit P. Haase wrote: So, yeah .. can someone please submit this package into cygwin =) .. i was surprised that dictd wasn't included yet - it's extremely useful I vote pro this package anyway. Would like to review it further. Where is a download? There is nothing to vote for. This is all speculation since we don't have a real maintainer. Please don't even bother voting for this until we have a volunteer. cgf
Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
Lapo wrote: Daniel Reed wrote: | Package: ccrypt 1.6-2 [2004-01-20] | Description: A utility for encrypting and decrypting files and streams |Proposer: Andreas Seidl |Proposal: http://cygwin.com/ml/cygwin-apps/2004-01/msg00112.html |Release directory (for use with setup.exe): | http://alice.fmi.uni-passau.de/~seidl/cygwin/ | http://alice.fmi.uni-passau.de/~seidl/cygwin/release/ccrypt/ccrypt-1.6-2.tar.bz2 | http://alice.fmi.uni-passau.de/~seidl/cygwin/release/ccrypt/ccrypt-1.6-2-src.tar.bz2 | http://alice.fmi.uni-passau.de/~seidl/cygwin/release/ccrypt/setup.hint | Status: Attained required 3 votes. Package available. |HOLD-UPS: No good to go review. http://cygwin.com/ml/cygwin-apps/2003-12/msg00288.html + http://cygwin.com/ml/cygwin-apps/2004-02/msg8.html I don't think we really need some emacs expert to check those .el and .elc files before accepting it? As written in http://cygwin.com/ml/cygwin-apps/2004-02/msg9.html I tried it and they worked; to my understanding, there can't / needn't be done more. However, a new problem might have popped up. Reading this thread http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html I wonder if there are legal problems for RedHat to distribute the ccrypt package? Andreas.
Re: i'd like to submit dictd into cygwin
Hallo Christopher, Am Sonntag, 22. Februar 2004 um 18:31 schriebst du: On Sun, Feb 22, 2004 at 10:27:17AM +0100, Gerrit P. Haase wrote: So, yeah .. can someone please submit this package into cygwin =) .. i was surprised that dictd wasn't included yet - it's extremely useful I vote pro this package anyway. Would like to review it further. Where is a download? There is nothing to vote for. This is all speculation since we don't have a real maintainer. Please don't even bother voting for this until we have a volunteer. Ok, I see, he didn't offer to maintain the package. Anyway, I compiled it and it runs fine, compiled without changes. Gerrit -- =^..^=
Re: a script to remove empty directories
Igor Pechtchanski wrote: Here's a variant of the above that works with spaces in filenames (but doesn't delete directories that contain only empty directories): find $ROOT -depth -type d -empty -print0 |xargs -0 rmdir -f However, does anyone care to submit a patch to the generic-build-script? Igor Igor, I'll try out the new script next week with one of my packages, and then I will send such a patch. Andreas.
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote: However, a new problem might have popped up. Reading this thread http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html I wonder if there are legal problems for RedHat to distribute the ccrypt package? You're right. There are. That means this package is removed from consideration. Sorry. cgf
RE: Pending patches for generic build script
On Sat, 21 Feb 2004, Rafael Kitover wrote:
-Original Message-
From: Igor Pechtchanski
Sent: Saturday, February 14, 2004 7:23 AM
Subject: Re: Pending patches for generic build script
On Fri, 13 Feb 2004, Charles Wilson wrote:
Igor Pechtchanski wrote:
false || true
As a bonus, this construct documents that this particular line can
return a false value.
I see. Well, this does look reasonably readable... Another problem with
set +e that I vaguely recall reading about is that it may not always be
propagated into functions... If you're willing to test this and make sure
it always works properly, and if nobody else protests, I'll consider
patching the generic-build-script.
Yes, I've never liked the silly looking ' \' syntax in the gbs. If
propagation of 'set +e' into functions is a problem, then just have each
function re-do it...
Chuck,
Ok, great! Since you're in favor of it (and you're the ultimate authority
on the gbs, I'm just temporarily handling the maintainer duties), it makes
me much more confident. I'll let Rafael test out the propagation of set
+e into functions, and then make the appropriate change.
[SNIP]
Umm, yes, since bash is in the Base category, any Cygwin machine will
have it, and it's not like the performance of the gbs itself is an
issue...
I think I'll wait until all the others' patches have been applied, though,
and then do it in one shot as one big change.
Rafael, if you're reading this, could you do the tests with both sh and
bash, and let me know if bash behaves better with respect to set +e? If
it does, we can switch the gbs to use bash.
Igor
Of course, waiting for the various gbs patches to go through first makes
perfect sense. I was just bringing up the issue for discussion, it's not an
emergency, we have plenty of those over on the main list :)
Yeah, I know what you mean. But changing the gbs via small incremental
improvements is the way to go, IMO. Using the set +e approach vs. the
current '' one will improve readability and make the gbs more robust.
FWIW, I've emptied my patch queue for now, so feel free to start testing.
What I was planning to do was make a canonical Cygwin package, kind of like GNU
Hello, using Hello as a base, and call it boffo to match the setup
documentation :) Eventually we'll be at a point were a new maintainer can get a
copy of boffo, tweak it, make their package, and have the package script do
some basic sanity checks. Also add some sort of selftest function for the gbs
against the canonical package, making development of the gbs itself a bit
easier (it can really suck when you have to wait half an hour for a build to go
through to check a minor tweak in the package script...)
I'm not sure I parsed all of this correctly, but I'll probably get it once
the patches actually arrive. :-)
Another feature I've dreamt up is have an update-script function for
the gbs, such that you could run pkg/CYGWIN-PATCHES/pkg.sh update-script
which would get the latest copy out of cvs or wherever is appropriate,
and patch the maintainer's script with the latest tweaks, as an
interactive patch if necessary.
Sure, just don't call it ${PKG}.sh, since that name is now recognized as
a postinstall script... The latest version of the gbs makes it somewhat
easier, since it now contains the CVS Id tag.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: a script to remove empty directories
On Sun, 22 Feb 2004, Andreas Seidl wrote: Igor Pechtchanski wrote: Here's a variant of the above that works with spaces in filenames (but doesn't delete directories that contain only empty directories): find $ROOT -depth -type d -empty -print0 |xargs -0 rmdir -f However, does anyone care to submit a patch to the generic-build-script? Igor Igor, I'll try out the new script next week with one of my packages, and then I will send such a patch. Andreas. Andreas, Great, thanks. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: libungif (Was: Re: Maintainers/Packages List, 2003-11-01)
lapo wrote: Frédéric L. W. Meunier wrote: The author returned from a coma and it got a new home - http://libungif.sourceforge.net/ . 4.1.1 was released some days ago. Thanks, i'll have time to take a look at it (and package it) probably in the beginning of next week ^_^ Speaking of which, I'm almost certain UNISYS's patent on LZW is now totally expired in most *MAJOR* countries. Can we please make libungif - libgif? Cheers, Nicholas
Re: libungif (Was: Re: Maintainers/Packages List, 2003-11-01)
On Sun, Feb 22, 2004 at 03:55:51PM -0500, Nicholas Wourms wrote: lapo wrote: Frédéric L. W. Meunier wrote: The author returned from a coma and it got a new home - http://libungif.sourceforge.net/ . 4.1.1 was released some days ago. Thanks, i'll have time to take a look at it (and package it) probably in the beginning of next week ^_^ Speaking of which, I'm almost certain UNISYS's patent on LZW is now totally expired in most *MAJOR* countries. Can we please make libungif - libgif? Oh, but it's still in effect for minor places like the EU, Canada, and Japan: http://www.kyz.uklinux.net/giflzw.php # The European patent EP0,129,439 covers four territories: Germany, France, # Britain and Italy. It expires on the 18th June 2004. # The Canadian patent CA1,223,965 expires on the 6th June 2004. # The Japanese patents 2,123,602 and 2,610,084 expire on the 20th June 2004. Give it 4 months.
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
cgf wrote: On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote: However, a new problem might have popped up. Reading this thread http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html I wonder if there are legal problems for RedHat to distribute the ccrypt package? Andreas, Next time, please keep it to yourself. Cheers, Nicholas
Re: [RFC] Would there be a need for a java-wrappers package?
pechtcha wrote: Hi, all, I would like to hear opinions on how useful a java-wrappers package would be. The package will contain a few shell scripts that allow users to invoke the regular Java SDK tools (java, javac, javadoc) from Cygwin, making them look like their Unix counterparts (i.e., POSIX filenames). The scripts would be updated versions of those posted in http://cygwin.com/ml/cygwin/2003-01/msg00174.html. There are a few reasons why I have misgivings about this. First off, some tools (notably Ant and Tomcat) recognize Cygwin and do something specific to Cygwin anyway, which will probably (most likely) get screwed up if the java they find looks like a Unix version (this did happen to me with Ant and Cygwin-native jikes). Secondly, the tools will certainly not be foolproof (although I'll try my best to make them as robust and autonomous as possible). Thirdly, java versioning may become a problem. You also might considier the problem which might arise if someone decided to package Kaffe. Perhaps it is time to investigate that system that Debian uses for managing packages with conflicting names. I think it is called update-alternatives or something like that... Anyhow, the scripts are still a nice idea :-). You might want to speak with Randall Schultz, he also has some really nice scripts I've been using for a year or two. Cheers, Nicholas
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
On Sun, Feb 22, 2004 at 04:27:06PM -0500, Nicholas Wourms wrote: cgf wrote: On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote: However, a new problem might have popped up. Reading this thread http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html I wonder if there are legal problems for RedHat to distribute the ccrypt package? Next time, please keep it to yourself. I'm sure you wouldn't enjoy it if Red Hat was taken to task for something that could have been caught early, decided that cygwin wasn't worth the hassle, and pulled it from sources.redhat.com. But, hey, thanks for clarifying just whom I can trust to be watching out for the project's interests.
Re: [RFC] Would there be a need for a java-wrappers package?
On Sun, 22 Feb 2004, Nicholas Wourms wrote: pechtcha wrote: Hi, all, I would like to hear opinions on how useful a java-wrappers package would be. The package will contain a few shell scripts that allow users to invoke the regular Java SDK tools (java, javac, javadoc) from Cygwin, making them look like their Unix counterparts (i.e., POSIX filenames). The scripts would be updated versions of those posted in http://cygwin.com/ml/cygwin/2003-01/msg00174.html. There are a few reasons why I have misgivings about this. First off, some tools (notably Ant and Tomcat) recognize Cygwin and do something specific to Cygwin anyway, which will probably (most likely) get screwed up if the java they find looks like a Unix version (this did happen to me with Ant and Cygwin-native jikes). Secondly, the tools will certainly not be foolproof (although I'll try my best to make them as robust and autonomous as possible). Thirdly, java versioning may become a problem. You also might considier the problem which might arise if someone decided to package Kaffe. Yes, but there's been talk about getting a Cygwin-native JVM for a while, with no apparent results. :-) Perhaps it is time to investigate that system that Debian uses for managing packages with conflicting names. I think it is called update-alternatives or something like that... We already have some packages with name conflicts (pdksh vs. astksh, possibly some others I can't recall at the moment), so I think one more won't make that much of a difference. Any solution that will apply to one will apply to all such packages, and thus is orthogonal to the issue. Anyhow, the scripts are still a nice idea :-). You might want to speak with Randall Schultz, he also has some really nice scripts I've been using for a year or two. Cheers, Nicholas Thanks for the suggestion, Nicholas. I believe we've discussed these scripts with Randall back when I first posted them, but I do hope he offers his input again when I ITP them here. I'd also like your input then, if only to say how they differ from Randall's scripts. FWIW, since these scripts are going to be Cygwin-specific, perhaps CGF might even consider hosting a CVS repository for them on cygwin-apps, so that others can send in patches against the development version... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: [RFC] Would there be a need for a java-wrappers package?
On Sun, Feb 22, 2004 at 05:03:16PM -0500, Igor Pechtchanski wrote: FWIW, since these scripts are going to be Cygwin-specific, perhaps CGF might even consider hosting a CVS repository for them on cygwin-apps, so that others can send in patches against the development version... Feel free to check them into the cygwin-apps repository. cgf
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
cgf wrote:
On Sun, Feb 22, 2004 at 04:27:06PM -0500, Nicholas Wourms wrote:
cgf wrote:
On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote:
However, a new problem might have popped up. Reading this thread
http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html
I wonder if there are legal problems for RedHat to distribute the ccrypt
package?
Next time, please keep it to yourself.
I'm sure you wouldn't enjoy it if Red Hat was taken to task for
something that could have been caught early, decided that cygwin wasn't
worth the hassle, and pulled it from sources.redhat.com.
No, I wouldn't, but I didn't intend on that being the only statement.
Consider this: The gpg which we distribute contains the *exact* same
cipher, AES{128,192,256}, as ccrypt plus gpg also has twofish
blowfish. The last time I checked, those two were also considered
strong encryption ciphers. Moreover, gpg can be used encrypt and
decrypt streams like ccrypt so, in a sense, they share similar
functionality. That's where I see the disconnect. Does this mean we
should ditch gpg as well or distribute a version with 128bit ciphers?
Frankly, I don't see why we should disqualified ccrypt because someone
thinks it might be a problem. Is it *really* a problem?
By his standard, RedHat has been breaking the law for years now, which
leads me to conclude that either:
A)The authorities don't care.
B)Red Hat doesn't care.
or
C)RedHat already has filed the necessary paperwork to allow it to
distribute binaries with strong encryption.
But, hey, thanks for clarifying just whom I can trust to be watching out
for the project's interests.
Hey, you certainly have a right to your opinion. The reality is that I
was trying to paste some text and accidentally sent that message before
it was complete. This reply contains some of the arguments I was
planning on including in that message to debunk his theory. Oh well,
that's all water under the bridge, believe what you want to believe...
I suppose I'll never get a gold star now ;-).
Cheers,
Nicholas
[1] The output of `gpg --help`:
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256
Compression: Uncompressed, ZIP, ZLIB
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
On Sun, Feb 22, 2004 at 05:53:47PM -0500, Nicholas Wourms wrote:
cgf wrote:
On Sun, Feb 22, 2004 at 04:27:06PM -0500, Nicholas Wourms wrote:
cgf wrote:
On Sun, Feb 22, 2004 at 07:39:49PM +0100, Andreas Seidl wrote:
However, a new problem might have popped up. Reading this thread
http://www.cygwin.com/ml/cygwin/2004-02/msg01103.html
I wonder if there are legal problems for RedHat to distribute the
ccrypt package?
Next time, please keep it to yourself.
I'm sure you wouldn't enjoy it if Red Hat was taken to task for
something that could have been caught early, decided that cygwin wasn't
worth the hassle, and pulled it from sources.redhat.com.
No, I wouldn't, but I didn't intend on that being the only statement.
Consider this: The gpg which we distribute contains the *exact* same
cipher, AES{128,192,256}, as ccrypt plus gpg also has twofish
blowfish.
The last time I checked, those two were also considered
strong encryption ciphers. Moreover, gpg can be used encrypt and
decrypt streams like ccrypt so, in a sense, they share similar
functionality. That's where I see the disconnect. Does this mean we
should ditch gpg as well or distribute a version with 128bit ciphers?
Frankly, I don't see why we should disqualified ccrypt because someone
thinks it might be a problem. Is it *really* a problem?
By his standard, RedHat has been breaking the law for years now, which
leads me to conclude that either:
A)The authorities don't care.
B)Red Hat doesn't care.
or
C)RedHat already has filed the necessary paperwork to allow it to
distribute binaries with strong encryption.
Hmm. I guess I haven't been as diligent as I should have been. I've
pulled gnupg from the distribution.
But, hey, thanks for clarifying just whom I can trust to be watching out
for the project's interests.
Hey, you certainly have a right to your opinion. The reality is that I
was trying to paste some text and accidentally sent that message before
it was complete.
Yeah, isn't that always a convenient excuse?
This reply contains some of the arguments I was planning on including
in that message to debunk his theory. Oh well, that's all water under
the bridge, believe what you want to believe... I suppose I'll never
get a gold star now ;-).
Thanks. I will certainly believe what i want to believe. I'd have a
hard time not doing that, in fact.
cgf
Re: [RFC] Would there be a need for a java-wrappers package?
On Sun, 22 Feb 2004, Christopher Faylor wrote: On Sun, Feb 22, 2004 at 05:03:16PM -0500, Igor Pechtchanski wrote: FWIW, since these scripts are going to be Cygwin-specific, perhaps CGF might even consider hosting a CVS repository for them on cygwin-apps, so that others can send in patches against the development version... Feel free to check them into the cygwin-apps repository. cgf Thanks. I was thinking of having a generic wrappers directory, with subdirectories for specific programs (java for now, but possibly also some sysinternals tools, etc). Comments? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Possible legal problems...
On Sun, Feb 22, 2004 at 06:38:11PM -0500, Christopher Faylor wrote: On Sun, Feb 22, 2004 at 05:53:47PM -0500, Nicholas Wourms wrote: By his standard, RedHat has been breaking the law for years now, which leads me to conclude that either: A)The authorities don't care. B)Red Hat doesn't care. or C)RedHat already has filed the necessary paperwork to allow it to distribute binaries with strong encryption. Hmm. I guess I haven't been as diligent as I should have been. I've pulled gnupg from the distribution. Should there be some generic announcement about this issue? The pertinent USA government website seems to be http://www.bxa.doc.gov/encryption/
setup.exe support for obsolete packages
Let me preface this by saying that I am not going to make a crass decision that creates a mess in the package list. Due to the reality of what Cygwin/X is as well as to recent events in the X community, I wish to rename the packages for Cygwin/X upon the next major release. Here is a brief summary of the reasons: 1) Cygwin/X has never been a distribution of XFree86 per se. We distribute libraries and clients that have patches applied by them, but we have never distributed the real fruit of their project, which is the XFree86 X Server (which is basically for *nix-like OSes with direct access to the graphics hardware). Our server is distinct from the XFree86 server. 2) Since we are not really distributing XFree86, it is misleading to call our packages XFree86-*. 3) Due to lack of cooperation, personality conflicts, and license issues, future Cygwin/X distributions will come from the X.Org Foundation project. The source code tree is hosted at freedesktop.org. Thus, having the XFree86 name in our packages becomes even more misleading. 4) We aim to slowly replace the X.Org Monolithic build with the X.Org Modular build (xserver, xlibs, and xapps projects at freedesktop.org). Thus, our xserver package may one day come from X.Org Monolithic and the next day (and from then on) it will come from the X.Org Modular tree. Eventually all of our libraries and clients will be in individual packages; it will be confusing to users if there is a compatibility package called xapps or xbin lying around that contains nothing. Dealing with such a rename with the current version of setup.exe would cause a real mess. If I rename the packages, then I have to leave about 12 XFree86-* packages out there that are empty. I would really like a way to suppress those packages from showing up as being newly installable, yet still getting the functionality of forcing them to be essentially uninstalled on the next upgrade that a user performs. I would also like the XFree86 category to be renamed to X11, though I believe this can be accomplished by just changing any setup.hints that refer to the XFree86 category to instead refer to the X11 category. As I said above, I'm not going to rename the packages en mass if I don't have a way to suppress the obsolete packages from being shown in setup.exe's list of installable packages. I'll just have to leave the package names mostly as is in that case. Is anyone interested in helping the Cygwin/X project by adding this functionality to Cygwin's setup.exe? I would really appreciate the help since I will be busy trying to get this X.Org release ready. On a side note, I can think of at least two ways to add this functionality: 1) Add a tag to setup.hint (which as to be processed by both setup.exe and the upset script) that indicates that a package should not be selectable for installation since it is obsolete. 2) Add a magic category call Obsolete. Just adapt setup.exe to not show this category, yet allow it to process all packages in this category as normal (e.g. replacing the real package prefix-foo-1.0-1 with the empty prefix-foo-1.0-2 compatibility package when prefix-foo is renamed to just foo). Thanks in advance, Harold
gnupg gone? [Was Re: Possible legal problem with ccrypt?]
On Sun, 22 Feb 2004, Christopher Faylor wrote:
On Sun, Feb 22, 2004 at 05:53:47PM -0500, Nicholas Wourms wrote:
cgf wrote:
I'm sure you wouldn't enjoy it if Red Hat was taken to task for
something that could have been caught early, decided that cygwin wasn't
worth the hassle, and pulled it from sources.redhat.com.
No, I wouldn't, but I didn't intend on that being the only statement.
Consider this: The gpg which we distribute contains the *exact* same
cipher, AES{128,192,256}, as ccrypt plus gpg also has twofish
blowfish. The last time I checked, those two were also considered
strong encryption ciphers. Moreover, gpg can be used encrypt and
decrypt streams like ccrypt so, in a sense, they share similar
functionality. That's where I see the disconnect. Does this mean we
should ditch gpg as well or distribute a version with 128bit ciphers?
Frankly, I don't see why we should disqualified ccrypt because someone
thinks it might be a problem. Is it *really* a problem?
By his standard, RedHat has been breaking the law for years now, which
leads me to conclude that either:
A)The authorities don't care.
B)Red Hat doesn't care.
or
C)RedHat already has filed the necessary paperwork to allow it to
distribute binaries with strong encryption.
Hmm. I guess I haven't been as diligent as I should have been. I've
pulled gnupg from the distribution.
Whoops... Good thing we left the package signing option in the
generic-build-script disabled by default... Would have been hard to
explain all the error messages to new package maintainers. :-)
I wonder, though (IANAL, and this may be heavily OT): does any of this
paperwork need to be filed for distributing pure source code for strong
encryption? If not, I have an idea that might just work, but I'd like to
hear an answer first.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: Possible legal problems...
On Sun, 22 Feb 2004, Joshua Daniel Franklin wrote: On Sun, Feb 22, 2004 at 06:38:11PM -0500, Christopher Faylor wrote: On Sun, Feb 22, 2004 at 05:53:47PM -0500, Nicholas Wourms wrote: By his standard, RedHat has been breaking the law for years now, which leads me to conclude that either: A)The authorities don't care. B)Red Hat doesn't care. or C)RedHat already has filed the necessary paperwork to allow it to distribute binaries with strong encryption. Hmm. I guess I haven't been as diligent as I should have been. I've pulled gnupg from the distribution. Should there be some generic announcement about this issue? The pertinent USA government website seems to be http://www.bxa.doc.gov/encryption/ We might also want to be proactive and add a What happened to 'gpg'? FAQ entry... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
XFree86-base no longer depends on XFree86-lib-compat
XFree86-lib-compat (provides old 4.2.0 libraries for compatibility with applications that have not been recompiled in almost a year) has been removed as a dependency of XFree86-base. This means that XFree86-lib-compat will no longer be installed in a default Cygwin/X installation. If you maintain any Cygwin/X packages that depend on the libraries in XFree86-lib-compat please recompile your application ASAP against the new libraries in the 4.3.0 releases. The XFree86-lib-compat package will be removed from the distribution when the next major release of Cygwin/X is made (within three months, possibly as soon as a month). In the mean time, if an application complains that it cannot find libX11-6.dll (or lib*-?.dll), then install the XFree86-lib-compat package and see if that fixes the problem. If it does, notify the maintainer of the package in question that they should recompile their package against recent X libraries. If it does not fix the problem, then your trouble lies elsewhere. Harold
Re: Possible legal problem with ccrypt? [Was: Re: Pending Packages List, 2004-02-13]
No, I wouldn't, but I didn't intend on that being the only statement.
Consider this: The gpg which we distribute contains the *exact* same
cipher, AES{128,192,256}, as ccrypt plus gpg also has twofish
blowfish.
The last time I checked, those two were also considered
strong encryption ciphers. Moreover, gpg can be used encrypt and
decrypt streams like ccrypt so, in a sense, they share similar
functionality. That's where I see the disconnect. Does this mean we
should ditch gpg as well or distribute a version with 128bit ciphers?
Frankly, I don't see why we should disqualified ccrypt because someone
thinks it might be a problem. Is it *really* a problem?
By his standard, RedHat has been breaking the law for years now, which
leads me to conclude that either:
A)The authorities don't care.
B)Red Hat doesn't care.
or
C)RedHat already has filed the necessary paperwork to allow it to
distribute binaries with strong encryption.
Hmm. I guess I haven't been as diligent as I should have been. I've
pulled gnupg from the distribution.
Hmm, I had the 1.2.4 version ready for a while, but forgot to mention
it.
Now it's too late. Anyone here with a bit web/ftp space to host the
cygwin package? (Preferably in europe?)
Volker
(Former cygwin gnupg mainainer)
--
PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D
pgp0.pgp
Description: PGP signature
