Re: What's in the NT branch
tis 2008-04-22 klockan 15:48 +0200 skrev Guido Serassio: > Wow, trying to fix a Squid copyright issue, I have found a problem > into another open source project, I'm very lucky :-( Yes.. it's fun to look into licensing issues.. > The following is the FreeBSD version, it's more simpler to adapt than > the GNU version, so, if you like, I will use this: > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/getopt.c The modern 3 clause BSD license is good for combining with GPL. Regards Henrik
Re: What's in the NT branch
Hi, At 13:37 22/04/2008, Henrik Nordstrom wrote: tis 2008-04-22 klockan 10:40 +0200 skrev Guido Serassio: > This is the version included into the MinGW runtime, I think that it > should be fine: > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/dirent.c?cvsroot=src Public domain is fine, even if it's debated if authors really can place content in the public domain.. OK. > On the getopt side: the MinGW version is the NetBSD one . :-( > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/getopt.c?cvsroot=src > And this should be the same version included in the SQUID_NT branch. Should file a bug on that with MinGW... it contradicts the published licensing requirements for the minggw runtime.. But not entirely clear if mingwex is considered an integral part of that... Wow, trying to fix a Squid copyright issue, I have found a problem into another open source project, I'm very lucky :-( The following is the FreeBSD version, it's more simpler to adapt than the GNU version, so, if you like, I will use this: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/getopt.c Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
tis 2008-04-22 klockan 10:40 +0200 skrev Guido Serassio: > This is the version included into the MinGW runtime, I think that it > should be fine: > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/dirent.c?cvsroot=src Public domain is fine, even if it's debated if authors really can place content in the public domain.. > On the getopt side: the MinGW version is the NetBSD one . :-( > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/getopt.c?cvsroot=src > And this should be the same version included in the SQUID_NT branch. Should file a bug on that with MinGW... it contradicts the published licensing requirements for the minggw runtime.. But not entirely clear if mingwex is considered an integral part of that... Regards Henrik > > And this version is also found on Cygwin. But Cygwin is licensed > under GPL. There is something wrong here ? > > Regards > > Guido > > > > - > > Guido Serassio > Acme Consulting S.r.l. - Microsoft Certified Partner > Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY > Tel. : +39.011.9530135 Fax. : +39.011.9781115 > Email: [EMAIL PROTECTED] > WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
Hi Henrik, At 12:59 13/03/2008, Henrik Nordstrom wrote: >On Tue, 2008-03-11 at 22:43 +0100, Guido Serassio wrote: > > > This file comes from the original work of Romeo Anghelache. > > After some search, I have found the original one from Apache 1.3: > > > http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/os/win32/readdir.c?view=markup > > If I remember right, the Apache License is not good for Squid. > >Correct. The Apache license is GPL incompatible due to minor stupid >things, but still incompatible. So we should find another one. May be that the version included into the MinGW runtime could be fine. I will test it, but I don't know when ... This is the version included into the MinGW runtime, I think that it should be fine: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/dirent.c?cvsroot=src On the getopt side: the MinGW version is the NetBSD one . :-( http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/getopt.c?cvsroot=src And this should be the same version included in the SQUID_NT branch. And this version is also found on Cygwin. But Cygwin is licensed under GPL. There is something wrong here ? Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
Hi Alex, At 23:49 13/03/2008, Alex Rousskov wrote: > I think that the main problem here is that there is still only one > Windows developer and this developer is not a full time developer: > I'm mainly a consultant, not a developer. I think the main problem is that folks committing changes have no sane way of testing those changes on Windows. We do not see Windows-specific bugs and have no sane way of detecting them. Thus, we cannot fix them. What we should probably do as a first step is to setup a Windows machine and compile Squid there as a part of nightly regression tests (and on-demand). Commits failing regression tests will be backed out. Can you provide and configure such a machine for remote ssh access to a restricted account that will run your regression test script? We can then integrate that with the Unix regression test bench. Let me to see how many CPU/memory/disk space is still available on the VMware host at may office. But configure a SSH access to a Windows machine is not so easy, because a native CMD prompt is needed for Visual Studio build, I'm testing some free product. If you cannot provide the machine with remote access, can you be responsible for configuring the [virtual] machine that I will provide? If yes, please let me know what Windows version it should run and what is the best way to enable you to access it for configuration. A good devel/test platform could be: - Windows server 2003 Standard Edition - Visual Studio 2005 - MSYS+MinGW - Cygwin The only usable protocol for the setup is the MS RDP (Terminal Server) protocol. But I hope to provide myself a Virtual Machine fot this job. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
On Thu, 2008-03-13 at 20:48 +0100, Guido Serassio wrote: > Too much times something like this is happened: > > - Update from CVS of my work dir > - Fix of build problems > - Commit of fixes > - Finished the little time that I have available for development, > usually during weekend > - Hope to do some test/debug during the next weekend > - During the next week someone commit changes in the source > - Update from CVS of my work dir (again during weekend) > - Fix of NEW build problems > - Commit of fixes > - Finished again the little time that I have available for > development just for fix NEW problems . > > This is very disappointing and is the reason because I like to have a > separated branch Having a separate branch will not fix the above problem, it will only mask it. It is pretty much the same as if you were to stop updating from HEAD: the problems will accumulate and become more difficult to fix when you decide to merge. I think it is perfectly fine to have a private branch if you want to commit often and merge infrequently. I just would not expect that to save you time or nerve cells, unfortunately. > I think that the main problem here is that there is still only one > Windows developer and this developer is not a full time developer: > I'm mainly a consultant, not a developer. I think the main problem is that folks committing changes have no sane way of testing those changes on Windows. We do not see Windows-specific bugs and have no sane way of detecting them. Thus, we cannot fix them. What we should probably do as a first step is to setup a Windows machine and compile Squid there as a part of nightly regression tests (and on-demand). Commits failing regression tests will be backed out. Can you provide and configure such a machine for remote ssh access to a restricted account that will run your regression test script? We can then integrate that with the Unix regression test bench. If you cannot provide the machine with remote access, can you be responsible for configuring the [virtual] machine that I will provide? If yes, please let me know what Windows version it should run and what is the best way to enable you to access it for configuration. Thank you, Alex.
Re: What's in the NT branch
On Thu, 2008-03-13 at 20:48 +0100, Guido Serassio wrote: > Too much times something like this is happened: > > - Update from CVS of my work dir > - Fix of build problems > - Commit of fixes > - Finished the little time that I have available for development, > usually during weekend > - Hope to do some test/debug during the next weekend > - During the next week someone commit changes in the source > - Update from CVS of my work dir (again during weekend) > - Fix of NEW build problems > - Commit of fixes > - Finished again the little time that I have available for > development just for fix NEW problems . So why do you update your workdir if you only want to test the stuff you had last weekend? You'll get extact the same breakage when updating your branch (i.e. running cvsmerge in the CVS setup, or bzr merge in the new bzr setup), so I am sorry but I don't see why keeping a shared branch helps this. I don't mind you having as many private branches for testing as you like to support your own workflow (thats after all one of the points why we selected bzr), but I do mind having stable binary releases made from a possibly different tree, or including sources not seen in the main tree. > >What aspect of Windows do you see as the most fragile part? > > The main problem is in the code that is touched from others developers. I would say the main problem is code changes only tested on one developers platform and not Windows.. > >- the socket/filedescriptor emulation? > > Many times very big problems here, and also with proprietary IPC and > IPv6 support. > This is the section where currently Squid 3.0 is failing on Windows. > I think that the forward port of the all 2.6+ related enhancements > could help the Squid 3.0 Windows support. Which Squid-2 changes do you have in mind there? > >- something else forgoten in the list above > > Different C/C++ compiler not always compatible with gcc and a totally > different run time library not based on glibc and not Posix > compliant. And many times this is a very big problem, true for both > Visual Studio and MinGW native environments. Yes, and this will always be seen for as long as we develop for more than one platform and compiler. But see above for my counter argument here.. Regards Henrik
Re: What's in the NT branch
Hi Henrik, At 12:59 13/03/2008, Henrik Nordstrom wrote: On Tue, 2008-03-11 at 22:43 +0100, Guido Serassio wrote: > This file comes from the original work of Romeo Anghelache. > After some search, I have found the original one from Apache 1.3: > http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/os/win32/readdir.c?view=markup > If I remember right, the Apache License is not good for Squid. Correct. The Apache license is GPL incompatible due to minor stupid things, but still incompatible. So we should find another one. May be that the version included into the MinGW runtime could be fine. I will test it, but I don't know when ... > My final intention is to have all the code changes merged into > STABLE/HEAD, but currently Squid 3.0 doesn't work at all on native > Windows, so some heavy and separated development work is still need > to fix all problems before any merge. That's fine. Such work should be done in a short lived development branch, and then merged upstream when it builds and runs, before the Windows release. > If this first step will be successful, and I'm not so sure about this > positive result , then there will the IPv6 on Windows challenge ... IPv6 on Windows is the same as above, but probably with more frequent merges to trunk. > I think that a more appropriate attribute for the Windows port is too > easily broken ... :-( > It's a very acrobatic piece of code :-) I don't see how keeping a separate port branch helps that... it's more of a sign that something needs redesign to support windows better. Too much times something like this is happened: - Update from CVS of my work dir - Fix of build problems - Commit of fixes - Finished the little time that I have available for development, usually during weekend - Hope to do some test/debug during the next weekend - During the next week someone commit changes in the source - Update from CVS of my work dir (again during weekend) - Fix of NEW build problems - Commit of fixes - Finished again the little time that I have available for development just for fix NEW problems . This is very disappointing and is the reason because I like to have a separated branch I think that the main problem here is that there is still only one Windows developer and this developer is not a full time developer: I'm mainly a consultant, not a developer. What aspect of Windows do you see as the most fragile part? The main problem is in the code that is touched from others developers. - integrity of tha build/make/project files? Not big problems here, usually the fix is add/remove a source file some the build project. But sometimes things was worse: i.e. the move from perl to awk for preprocessing. - the socket/filedescriptor emulation? Many times very big problems here, and also with proprietary IPC and IPv6 support. This is the section where currently Squid 3.0 is failing on Windows. I think that the forward port of the all 2.6+ related enhancements could help the Squid 3.0 Windows support. - rename of open files No problems here. - windows specific support features (i.e. service code, dns registry glue etc) Usually not so big problems here, because all the code is in Windows specific sources. - something else forgoten in the list above Different C/C++ compiler not always compatible with gcc and a totally different run time library not based on glibc and not Posix compliant. And many times this is a very big problem, true for both Visual Studio and MinGW native environments. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
On Tue, 2008-03-11 at 22:43 +0100, Guido Serassio wrote: > This file comes from the original work of Romeo Anghelache. > After some search, I have found the original one from Apache 1.3: > http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/os/win32/readdir.c?view=markup > If I remember right, the Apache License is not good for Squid. Correct. The Apache license is GPL incompatible due to minor stupid things, but still incompatible. > My final intention is to have all the code changes merged into > STABLE/HEAD, but currently Squid 3.0 doesn't work at all on native > Windows, so some heavy and separated development work is still need > to fix all problems before any merge. That's fine. Such work should be done in a short lived development branch, and then merged upstream when it builds and runs, before the Windows release. > If this first step will be successful, and I'm not so sure about this > positive result , then there will the IPv6 on Windows challenge ... IPv6 on Windows is the same as above, but probably with more frequent merges to trunk. > I think that a more appropriate attribute for the Windows port is too > easily broken ... :-( > It's a very acrobatic piece of code :-) I don't see how keeping a separate port branch helps that... it's more of a sign that something needs redesign to support windows better. What aspect of Windows do you see as the most fragile part? - integrity of tha build/make/project files? - the socket/filedescriptor emulation? - rename of open files - windows specific support features (i.e. service code, dns registry glue etc) - something else forgoten in the list above Regards Henrik
Re: What's in the NT branch
Hi Henrik,, At 21:52 09/03/2008, Henrik Nordstrom wrote: On Sat, 2008-03-01 at 10:57 +0100, Guido Serassio wrote: > This is very critical on the side of the DOS/Unix > text format: Visual Studio doesn't work with Unix text files. > Usually I commit the files on this directory only from Windows machines. Thats easy to deal with, in fact most likely not really an issue unless you do a checkout from a different environment than you build.. Sometime I have seen strange things with Windows files changing unexpectedly the text file format even on the same platform, I hope that bzr will be better. > > lib/getopt.c. Copy from NetBSD with a license incompatible with GPL. > > Right, someone could provide a GPL version ? One from either - FreeBSD - uclibc - glibc - or a number of other projects should be fine.. but I suspect the glibc one has to much of dependencies.. BSD / GPL / Public Domain OK, I will take a look for another version. > > > port/win32/src/encrypt.c. 56 bit DES encryption. Still under export > > > control in some regoins of the world, but not really a problem. Could be > > > in lib/ to support other platforms without crypt(). > > As I know, it's missing only on Visual Studio. I can imagine it missing on may other platforms as well.. it's no longer considered a good pasword hashing method. OK. > > > port/win32/src/readdir.c. Unknown copyright or license. > > > > > This is also unknown to me. Not good. From where did you get it? This file comes from the original work of Romeo Anghelache. After some search, I have found the original one from Apache 1.3: http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/os/win32/readdir.c?view=markup If I remember right, the Apache License is not good for Squid. > Just discovered another reason to maintain a > separate 3.0 STABLE NT branch: currently STABLE > 3.0 doesn't work on Windows, so this the only > STABLE based branch where to develop and test the needed changes. Not convinced this is a reason. If you need to make changes for Windows then it's best if these changes is done in a way which fits all.. And having code, even if Windows specific, in the windows branch is a very bad thing as it makes it a lot harder for the project to audit the codebase. My final intention is to have all the code changes merged into STABLE/HEAD, but currently Squid 3.0 doesn't work at all on native Windows, so some heavy and separated development work is still need to fix all problems before any merge. If this first step will be successful, and I'm not so sure about this positive result , then there will the IPv6 on Windows challenge ... > Regarding to Squid 2, if in the future there is > no plan for intrusive changes on the IPC/FD side > that could affect the Windows port, a merge into > a single branch could be considered. Who knows. But I don't see the windows port so special in that regard. We already have differences between many platforms. Sure, Windows is a little more different, but not very much. I think that a more appropriate attribute for the Windows port is too easily broken ... :-( It's a very acrobatic piece of code :-) Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
On Sun, 2008-03-09 at 21:52 +0100, Henrik Nordstrom wrote: > On Sat, 2008-03-01 at 10:57 +0100, Guido Serassio wrote: > > This is very critical on the side of the DOS/Unix > > text format: Visual Studio doesn't work with Unix text files. > > Usually I commit the files on this directory only from Windows machines. > > Thats easy to deal with, in fact most likely not really an issue unless > you do a checkout from a different environment than you build.. > > Just discovered another reason to maintain a > > separate 3.0 STABLE NT branch: currently STABLE > > 3.0 doesn't work on Windows, so this the only > > STABLE based branch where to develop and test the needed changes. > > Not convinced this is a reason. If you need to make changes for Windows > then it's best if these changes is done in a way which fits all.. > > And having code, even if Windows specific, in the windows branch is a > very bad thing as it makes it a lot harder for the project to audit the > codebase. > ... I don't see the windows port so special in that regard. > We already have differences between many platforms. Sure, Windows is a > little more different, but not very much. I agree with Henrik. I know that maintaining a single code base for native Windows and Unix projects is a pain (been there), but it is becoming a lesser pain with modern VCSs and the alternative (permanently separate VCS branches) is worse. Alex.
Re: What's in the NT branch
On Sat, 2008-03-01 at 10:57 +0100, Guido Serassio wrote: > This is very critical on the side of the DOS/Unix > text format: Visual Studio doesn't work with Unix text files. > Usually I commit the files on this directory only from Windows machines. Thats easy to deal with, in fact most likely not really an issue unless you do a checkout from a different environment than you build.. > > lib/getopt.c. Copy from NetBSD with a license incompatible with GPL. > > Right, someone could provide a GPL version ? One from either - FreeBSD - uclibc - glibc - or a number of other projects should be fine.. but I suspect the glibc one has to much of dependencies.. BSD / GPL / Public Domain > > > port/win32/src/encrypt.c. 56 bit DES encryption. Still under export > > > control in some regoins of the world, but not really a problem. Could be > > > in lib/ to support other platforms without crypt(). > > As I know, it's missing only on Visual Studio. I can imagine it missing on may other platforms as well.. it's no longer considered a good pasword hashing method. > > > port/win32/src/readdir.c. Unknown copyright or license. > > > > > This is also unknown to me. Not good. From where did you get it? > Just discovered another reason to maintain a > separate 3.0 STABLE NT branch: currently STABLE > 3.0 doesn't work on Windows, so this the only > STABLE based branch where to develop and test the needed changes. Not convinced this is a reason. If you need to make changes for Windows then it's best if these changes is done in a way which fits all.. And having code, even if Windows specific, in the windows branch is a very bad thing as it makes it a lot harder for the project to audit the codebase. > Regarding to Squid 2, if in the future there is > no plan for intrusive changes on the IPC/FD side > that could affect the Windows port, a merge into > a single branch could be considered. Who knows. But I don't see the windows port so special in that regard. We already have differences between many platforms. Sure, Windows is a little more different, but not very much. Regards Henrik
Re: What's in the NT branch
On Sat, 2008-03-01 at 10:57 +0100, Guido Serassio wrote: > >On Sun, 2008-02-24 at 21:26 +0100, Henrik Nordström wrote: > > > Guido, > > > > > > what's actually in the NT branch today? Is it only the "makefiles", or > > > is there any actual source changes which should not be merged to the > > > main branch? > > > > > > If it's only the "makefiles" then I propose those are stored in the main > > > branch (HEAD and SQUID_3_0) directly > > > > > > Looking at a diff... > > > > > > port directory tree with "makefiles" [generally OK] > > This is very critical on the side of the DOS/Unix > text format: Visual Studio doesn't work with Unix text files. > Usually I commit the files on this directory only from Windows machines. I hope bzr can convert new lines based on the platform like subversion does. This should free you from warring about text file "formats". Robert? > Just discovered another reason to maintain a > separate 3.0 STABLE NT branch: currently STABLE > 3.0 doesn't work on Windows, so this the only > STABLE based branch where to develop and test the needed changes. I think this is a different issue. If all other problems are resolved, you can certainly have a branch for Windows work, but it can use the same source directory layout and files as HEAD, and the changes will be merged as needed. In other words, it will be similar to other branches we work on now (e.g., AsyncCalls or SslBump). Alex.
Re: What's in the NT branch
Hi Alex & Henrik, At 18:40 25/02/2008, Alex Rousskov wrote: On Sun, 2008-02-24 at 21:26 +0100, Henrik Nordström wrote: > Guido, > > what's actually in the NT branch today? Is it only the "makefiles", or > is there any actual source changes which should not be merged to the > main branch? > > If it's only the "makefiles" then I propose those are stored in the main > branch (HEAD and SQUID_3_0) directly > > Looking at a diff... > > port directory tree with "makefiles" [generally OK] This is very critical on the side of the DOS/Unix text format: Visual Studio doesn't work with Unix text files. Usually I commit the files on this directory only from Windows machines. > > lib/getopt.c. Copy from NetBSD with a license incompatible with GPL. Right, someone could provide a GPL version ? > > port/win32/src/encrypt.c. 56 bit DES encryption. Still under export > control in some regoins of the world, but not really a problem. Could be > in lib/ to support other platforms without crypt(). As I know, it's missing only on Visual Studio. > > port/win32/src/readdir.c. Unknown copyright or license. > This is also unknown to me. > I don't see a good reason why the port tree cannot be in the main > branch, except for the trivial reservations above... FWIW, I asked Guido a related question and made a similar "sore in the main branch" suggestion a few months(?) ago. At that time, Guido was positive he needs Windows-specific branches; he explained why he thought so. Please try to find that thread in the squid-dev archive for more info so that Guido does not have to repeat himself. Just discovered another reason to maintain a separate 3.0 STABLE NT branch: currently STABLE 3.0 doesn't work on Windows, so this the only STABLE based branch where to develop and test the needed changes. Regarding to Squid 2, if in the future there is no plan for intrusive changes on the IPC/FD side that could affect the Windows port, a merge into a single branch could be considered. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
On Sun, 2008-02-24 at 21:26 +0100, Henrik Nordström wrote: > Guido, > > what's actually in the NT branch today? Is it only the "makefiles", or > is there any actual source changes which should not be merged to the > main branch? > > If it's only the "makefiles" then I propose those are stored in the main > branch (HEAD and SQUID_3_0) directly > > Looking at a diff... > > port directory tree with "makefiles" [generally OK] > > lib/getopt.c. Copy from NetBSD with a license incompatible with GPL. > > port/win32/src/encrypt.c. 56 bit DES encryption. Still under export > control in some regoins of the world, but not really a problem. Could be > in lib/ to support other platforms without crypt(). > > port/win32/src/readdir.c. Unknown copyright or license. > > I don't see a good reason why the port tree cannot be in the main > branch, except for the trivial reservations above... FWIW, I asked Guido a related question and made a similar "sore in the main branch" suggestion a few months(?) ago. At that time, Guido was positive he needs Windows-specific branches; he explained why he thought so. Please try to find that thread in the squid-dev archive for more info so that Guido does not have to repeat himself. Thank you, Alex.
What's in the NT branch
Guido, what's actually in the NT branch today? Is it only the "makefiles", or is there any actual source changes which should not be merged to the main branch? If it's only the "makefiles" then I propose those are stored in the main branch (HEAD and SQUID_3_0) directly Looking at a diff... port directory tree with "makefiles" [generally OK] lib/getopt.c. Copy from NetBSD with a license incompatible with GPL. port/win32/src/encrypt.c. 56 bit DES encryption. Still under export control in some regoins of the world, but not really a problem. Could be in lib/ to support other platforms without crypt(). port/win32/src/readdir.c. Unknown copyright or license. I don't see a good reason why the port tree cannot be in the main branch, except for the trivial reservations above... Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
