Re: Orphaned packages
Yes, that sounds accurate. I was going to try to hang on to a few... but we ended up moving from California to NYC shortly afterward and I've just got settled enough to check mail in this list, so I guess I have to admit that I will probably never get around to working on Cygwin packages again :( Oh well, I still use Cygwin at work! :) Harold Christopher Faylor wrote: Corinna, We also found out that all of Harold Hunt's packages are orphaned, most notably ImageMagick could use a maintainer. cgf
Re: ImageMagick problems
Corinna Vinschen wrote: From my list of packages you maintained so far, I'm missing cppunit distcc links Okay, missed those too. I think I should let those go. I haven't used them personally in over a year. I'll wait to post another compiled list of keeping/resigning for a few days, in case someone discovers some other packages that I used to maintain. Harold
Re: ImageMagick problems
Christopher Faylor wrote: On Sat, Aug 19, 2006 at 12:23:50PM -0700, Harold L Hunt II wrote: Actually, it was kinda random that I even looked at the list today. I've been doing other things for a long time now: http://www.starnet.com/huntntech I knew you were doing other things but when we queried package maintainers a while ago, I thought you were still maintaining a few packages. I guess it just takes a long time to realize that you haven't been doing something and that, even though you try to convince yourself that you might, you just aren't likely to start doing it again. I think that package maintainer's query was at least six months ago; when I responded I thought there might be a chance that I'd get heavily involved again, but that doesn't seem to have materialized. Thus, it seems that it is time to admit that I probably won't soon be as involved as I once was. I guess it is safe to say that I will not be able to maintain complex Cygwin packages anymore. Thus, I am letting go of the following (from the maintainer's list posted in 2003-11 http://www.cygwin.com/ml/cygwin-apps/2003-11/msg00260.html): * *ImageMagick* (last build posted 2004/08/11, mine) * *GraphicsMagick* (last build posted 2004/07/17, mine) * fontconfig/libfontconfig* (last build posted 2004/03/11, most likely mine) * freetype/libfreetype* (last build posted 2005/09/07, this might have been mine) * libXft* (last build posted 2004/03/23, most likely mine) * ddd (last build posted 2004/06/16, mine) * lesstif (Brian Ford has this now, right?) * fvwm (last build posted 2003/11/27, mine) * openbox (last build posted 2003/11/27, mine)) * nedit (last build posted 2004/10/16, mine) * transfig (last build posted 2003/11/27, mine) * xfig, xfig-lib (last build posted 2004/02/12, mine) * WindowMaker (last build posted 2005/06/28, I think that was mine) * x2x (last build posted 2004/04/07, mine) * Xaw3d (last build posted 2004/01/13, mine) * xgraph (last build posted 2003/11/27, mine) Packages I can keep: * tnef * xmon * xterm I believe that covers the entire list. Hopefully new maintainers can be found for these packages as new releases are required. Weren't you/aren't you maintaining wget? Yeah, sorry, forgot about that one (the source wasn't on the machine that I was using to get my list, so I missed it). New list of packages I can keep: * tnef * wget * xmon * xterm Harold
[ITP] tnef - MS-TNEF file unpacker
Home Page = http://sourceforge.net/projects/tnef Debian has tnef in stable = http://packages.debian.org/stable/text/tnef Download links == http://homer.starnet.com/~hunth/cygwin/release/tnef/tnef-1.3.4-1.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/tnef/tnef-1.3.4-1-src.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/tnef/setup.hint setup.hint == sdesc: Unpacks MS-TNEF email attachments ldesc: TNEF provides a way to unpack those pesky Microsoft MS-TNEF MIME attachments. It operates like tar in order to upack any files which may have been put into the MS-TNEF attachment instead of being attached seperately. category: Archive Mail requires: cygwin I have already used it on my computer today to unpack one of those winmail.dat files and it worked fine... the only question I have is the category. Debian put it in 'text', but I thought 'Mail' and 'Archive' were more appropriate places where it should be found. Comments? Harold
Please upload: tnef-1.3.4-1
http://homer.starnet.com/~hunth/cygwin/release/tnef/tnef-1.3.4-1.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/tnef/tnef-1.3.4-1-src.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/tnef/setup.hint Harold
Re: Please *wait* before sending cygwin-announce messages
Christopher Faylor wrote: [snip] Please *do* send your upload announcements here, but just the raw facts, please, no descriptions of why you are updating or what the new features are. Just URLs are all that is required. [snip] Let me see if I am reading this correctly: When sending a message to cygwin-announce, it should not contain any information about the motivation for the update (e.g. sync with upstream or Cygwin-specific bug fix), nor should it contain a list of features and/or bug fixes? When you say just URLs are required, did you mean to say if the information is available on the web (e.g. on an upstream project web page), just include a URL instead of copying and pasting? I can agree with that, that would cut out a lot of information that is available elsewhere. But the lack of a description of the motivation for the update seems a little odd, that information is simply not available elsewhere. Did I misread the request? Harold
Re: Please *wait* before sending cygwin-announce messages
Christopher Faylor wrote: On Wed, Dec 07, 2005 at 05:10:06PM -0800, Harold L Hunt II wrote: Christopher Faylor wrote: Please *do* send your upload announcements here, but just the raw facts, [snip] Let me see if I am reading this correctly: When sending a message to cygwin-announce, here == cygwin-apps, not cygwin-announce. To summarize, the steps are: 1) send an upload announcement here (cygwin-apps) with just the bare facts required to get the packages onto sourceware. 2) someone says Done, indicating that the packages have been uploaded. 3) you, having waited patiently here (cygwin-apps) for notice that your packages are now uploaded to sourceware.org then immediately send out an announcement to cygwin-announce (there). Said announcement should contain unsubscribe details. Ah ha, that's it (the here being cygwin-apps), thanks for the clarification. Harold
Please upload: wget-1.10.2-1
Files = http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.2-1.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.2-1-src.tar.bz2 unchanged: http://homer.starnet.com/~hunth/cygwin/release/wget/setup.hint Changes === 2005-11-15 Harold L Hunt II - Upstream fix for remotely exploitable vulnerability: - http://www.mail-archive.com/wget@sunsite.dk/msg08300.html - http://www.mail-archive.com/wget@sunsite.dk/msg08295.html - Thanks to Alan Dobkin for the heads up. Harold setup.hint == sdesc: Utility to retrieve files from the WWW via HTTP and FTP ldesc: GNU Wget is a file retrieval utility which can use either the HTTP, HTTPS, or FTP protocols. Wget features include the ability to work in the background while you're logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability. category: Web requires: openssl libintl3 libiconv2 bash cygwin
Re: Please upload: wget-1.10.2-1
Both. Harold Christopher Faylor wrote: On Wed, Nov 16, 2005 at 01:42:07PM -0800, Harold L Hunt II wrote: Files = http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.2-1.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.2-1-src.tar.bz2 unchanged: http://homer.starnet.com/~hunth/cygwin/release/wget/setup.hint Changes === 2005-11-15 Harold L Hunt II - Upstream fix for remotely exploitable vulnerability: - http://www.mail-archive.com/wget@sunsite.dk/msg08300.html - http://www.mail-archive.com/wget@sunsite.dk/msg08295.html - Thanks to Alan Dobkin for the heads up. Uploaded. Which old version should I remove? cgf
Re: Security Advisory and Request for Wget Update: 1.10.2
Alan, Thanks for the heads up, but next time I'll take the notice without the lip, thank you. Harold Alan Dobkin wrote: FYI, Wget 1.10.2 was released over a month ago (on October 13, 2005): The latest stable version of Wget is 1.10.2. This release contains fixes for a major security problem: a remotely exploitable buffer overflow vulnerability in the NTLM authentication code. All Wget users are strongly encouraged to upgrade their Wget installation to the last release. http://www.mail-archive.com/wget@sunsite.dk/msg08295.html http://www.mail-archive.com/wget@sunsite.dk/msg08300.html It seems that Harold Hunt is the new wget maintainer, and I do not wish to take his place, but new releases such as this (especially security updates that affect Windows) should be provided in a timely manner. Thanks, Alan P. S. -- Apparently this is the same bug that also affected cURL, which has no current maintainer On 10/23/2005 3:46 PM, Yaakov S (Cygwin Ports) wrote: cURL is vulnerable to a buffer overflow which could lead to the execution of arbitrary code. Solution: upgrade to 7.15.0. Workaround until solved: Disable NTLM authentication by not using the --anyauth or --ntlm options when using cURL (the command line version). Workarounds for programs that use the cURL library depend on the configuration options presented by those programs. http://security.gentoo.org/glsa/glsa-200510-19.xml http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3185 http://www.idefense.com/application/poi/display?id=322type=vulnerabilities Yaakov
Re: 4th summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
The following is useful information from me... I'm giving some guidance on decisions that need to be made, but I've long since relinquished any responsibility to make those decisions, so just ignore my advice if you disagree, rather than getting all uppity about how I'm not in charge and shouldn't be making these sorts of decisions. Corinna Vinschen wrote: On Sep 15 18:45, Corinna Vinschen wrote: LIST 3: PACKAGES WITHOUT REPLY FROM MAINTAINER SO FAR = [...] cygwin-x-doc I'm listed as the maintainer in the README, but I haven't been maintaining this since mid-2004. Alexander Gottwald would taken this over, but he's not involved with Cygwin/X anymore, so I guess this should fall to Alan H. But, if no one takes it, it needs to go away and people can access Cygwin/X docos on the website. [...] x-start-menu-icons x-startup-scripts Alexander Gottwald is listed as the maintainer for these, but he isn't involved with Cygwin/X anymore, so these should go to Alan H. These can't really be removed... so Alan H really needs to find a maintainer for them if he doesn't want them. x2x Thomas Chadwick used to maintain this... but he and I worked closely on it. I'm not interested if he doesn't reply, so this might be up for grabs or it might just go away. [...] xwinclip I'm still listed as the maintainer of this and I declare it obsolete. I'm not going to maintain it anymore and it doesn't need to exist anymore, so please remove it from the distribution. xwinwm I'm still listed as the maintainer of this. This is a window manager that goes hand-in-hand with a feature in Cygwin/X... but that feature was never finished and hasn't been updated since April of 2004. I claim this is dead... but it should probably be assigned to Alan H. and he can request that it be removed if he isn't going to pursue it any further. Harold
Re: 4th summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
Igor Pechtchanski wrote: On Mon, 10 Oct 2005, Harold L Hunt II wrote: The following is useful information from me... [snip] xwinclip I'm still listed as the maintainer of this and I declare it obsolete. I'm not going to maintain it anymore and it doesn't need to exist anymore, so please remove it from the distribution. Harold, I recall that there was an issue with XWin -clipboard -query, where in certain circumstances the clipboard thread didn't have permission to connect to the X server. This was one argument for having a separate xwinclip application. Your comment above implies that this issue is fixed in the newer X releases, right? Igor I only put about a month into fixing that... the final design is that we register our own cookie with the server so that we can always connect, plus we overload ProcEstablishConnection to wait until several clients have connected (usually the Xdm server) before we connect; this causes us to be inserted into the connection list only after the Xdm server has killed all existing client connections. xwinclip is an abomination that still steals the ownership of the X selection and forces copies of data that are never pasted. If there are any remaining problems with the new clipboard system and Xdmcp (I'm pretty sure there are not), then they need to be fixed (not too hard, this would just be tweaks to the existing work-around), rather than providing the broken alternative that is xwinclip. Here's the last time I fixed a problem related to the clipboard support and Xdmcp (21 months to the day): http://x.cygwin.com/devel/server/changelog-100.html Release 4.3.0-34 Released: 2004-01-10 0200 EST Harold
Re: ATTN Harold Hunt - Re: https no longer supported with wget v1.10.1
I just got this message today (after receiving almost every other message between now and then). Yesterday Hack's messages and my own messages were also delayed by several hours. I'm sure I'm not the only one... Harold Christopher Faylor wrote: On Mon, Oct 03, 2005 at 09:48:47AM -0700, Harold L Hunt II wrote: Corinna Vinschen wrote: On Oct 2 20:58, Harold L Hunt II wrote: Got it... One question though: when you built it, was it statically linking the ssl libs? When I just rebuilt it, it statically linked them... which makes me think that the openssl install dependency is wrong, since I'm pretty sure there aren't any config files needed from the openssl package and the dynamic libraries, by definition, aren't needed for statically linked apps... What do you think? I know, you didn't ask me, but I'd prefer if applications are linked against the OpenSSL shared libs for, hopefully, obvious reasons. Right, I prefer that as well... I figured the preference was shared. No pun intended :) What I wanted to know, though, was historically whether wget has linked against the static or shared libs so I would know if I was missing something that caused the shared libs to work. While we're debating shared vs. static can we get an announcement for the version that's currently available? cgf
Re: ATTN Harold Hunt - Re: https no longer supported with wget v1.10.1
Corinna Vinschen wrote: On Oct 2 20:58, Harold L Hunt II wrote: Got it... One question though: when you built it, was it statically linking the ssl libs? When I just rebuilt it, it statically linked them... which makes me think that the openssl install dependency is wrong, since I'm pretty sure there aren't any config files needed from the openssl package and the dynamic libraries, by definition, aren't needed for statically linked apps... What do you think? I know, you didn't ask me, but I'd prefer if applications are linked against the OpenSSL shared libs for, hopefully, obvious reasons. Right, I prefer that as well... I figured the preference was shared. No pun intended :) What I wanted to know, though, was historically whether wget has linked against the static or shared libs so I would know if I was missing something that caused the shared libs to work. Unfortunately, it looks like wget must have always been linking against the static ssl libs because it uses a custom 550 line m4 script to find the ssl libs and it doesn't seem to know anything about Cygwin or to prefer shared over static libs. I don't know that I want to open that can of worms just yet, since I usually end up having to fix about a weeks worth of bad autoconf in order to get things working again. In the mean time, I think I'll release the statically linked version to maintain the status quo. Harold
Re: ATTN Harold Hunt - Re: https no longer supported with wget v1.10.1
Corinna Vinschen wrote: On Oct 3 09:48, Harold L Hunt II wrote: Corinna Vinschen wrote: On Oct 2 20:58, Harold L Hunt II wrote: Got it... One question though: when you built it, was it statically linking the ssl libs? When I just rebuilt it, it statically linked them... which makes me think that the openssl install dependency is wrong, since I'm pretty sure there aren't any config files needed from the openssl package and the dynamic libraries, by definition, aren't needed for statically linked apps... What do you think? I know, you didn't ask me, but I'd prefer if applications are linked against the OpenSSL shared libs for, hopefully, obvious reasons. Right, I prefer that as well... I figured the preference was shared. No pun intended :) What I wanted to know, though, was historically whether wget has linked against the static or shared libs so I would know if I was missing something that caused the shared libs to work. Unfortunately, it looks like wget must have always been linking against the static ssl libs because it uses a custom 550 line m4 script to find the ssl libs and it doesn't seem to know anything about Cygwin or to prefer shared over static libs. I don't know that I want to open that can of worms just yet, since I usually end up having to fix about a weeks worth of bad autoconf in order to get things working again. In the mean time, I think I'll release the statically linked version to maintain the status quo. Dunno about cans of worms, but wget is certainly linked against shared ssl libs on Linux, too. Isn't there some simple way of linking against `-lssl -lcrypto' instead of `/usr/lib/libssl.a /usr/lib/libcrypto.a'? As I said, they're using a custom 550 line script to find the ssl libs, and here is what it finds: configure:10451: checking for libssl configure:10483: gcc -o conftest.exe -O2 conftest.c /usr/lib/libssl.a /usr/lib/libcrypto.a 5 configure:10489: $? = 0 configure:10493: test -z || test ! -s conftest.err configure:10496: $? = 0 configure:10499: test -s conftest.exe configure:10502: $? = 0 configure:10516: result: yes configure:10525: checking how to link with libssl configure:10527: result: /usr/lib/libssl.a /usr/lib/libcrypto.a wget is not using automake, nor are they using libtool, so I'm pretty sure the cleanest way to fix the ssl lib problem if going to be diving into that 550 line lib detection script, which I think can be appropriately called a can of worms. One nice thing that I just learned is that they are at least using autoconf 2.59, so at least I won't have to upgrade an old crufty autoconf syntax to the shiny new autoconf syntax, which is usually about half of the can of worms. Harold
Please upload: wget-1.10.1-2
Files = http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.1-2.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.1-2-src.tar.bz2 unchanged: http://homer.starnet.com/~hunth/cygwin/release/wget/setup.hint Changes === 2005-10-02 Harold L Hunt II - rebuild with SSL support re-enabled (Thanks to Hack!) Harold setup.hint == sdesc: Utility to retrieve files from the WWW via HTTP and FTP ldesc: GNU Wget is a file retrieval utility which can use either the HTTP, HTTPS, or FTP protocols. Wget features include the ability to work in the background while you're logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability. category: Web requires: openssl libintl3 libiconv2 bash cygwin
Re: ATTN Harold Hunt - Re: https no longer supported with wget v1.10.1
Hack, Great idea... seemed to work just fine on this end. I've just posted a 1.10.1-2 for upload that has ssl support re-enabled. Harold Hack Kampbjorn wrote: Harold L Hunt II wrote: What I wanted to know, though, was historically whether wget has linked against the static or shared libs so I would know if I was missing something that caused the shared libs to work. Yes, it has historically used shared libs also for ssl. Unfortunately, it looks like wget must have always been linking against the static ssl libs because it uses a custom 550 line m4 script to find the ssl libs and it doesn't seem to know anything about Cygwin or to prefer shared over static libs. I don't know that I want to open that can of worms just yet, since I usually end up having to fix about a weeks worth of bad autoconf in order to get things working again. In the mean time, I think I'll release the statically linked version to maintain the status quo. They removed libtool support somewhere between 1.9.1 and 1.10.1. This seems to have caused this problem. I've tried with different --with-ssl arguments but it doesn't seem to consistenly find '-lssl -lcrypto'. The easiest thing is to just force it to use the -l libraries over the .a libs $ diff -u wget-1.10.1/Makefile.in* --- wget-1.10.1/Makefile.in 2005-10-03 19:56:34.153712800 +0200 +++ wget-1.10.1/Makefile.in.orig2005-06-27 00:06:49.0 +0200 @@ -57,7 +57,7 @@ CFLAGS = @CFLAGS@ CPPFLAGS = @CPPFLAGS@ DEFS = @DEFS@ -DSYSTEM_WGETRC=\$(sysconfdir)/wgetrc\ -DLOCALEDIR=\$(localedir)\ -LIBS = @LIBS@ @LTLIBSSL@ +LIBS = @LIBS@ @LIBSSL@ LDFLAGS = @LDFLAGS@ # Note: it's only @LIBSSL@ - @LTLIBSSL@ $ cygcheck wget-1.10.1/.build/src/wget.exe wget-1.10.1/.build/src/wget.exe d:\cygwin\bin\cygcrypto-0.9.8.dll d:\cygwin\bin\cygwin1.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\NTDLL.DLL C:\WINNT\System32\KERNEL32.DLL C:\WINNT\System32\RPCRT4.DLL d:\cygwin\bin\cygintl-3.dll d:\cygwin\bin\cygiconv-2.dll d:\cygwin\bin\cygssl-0.9.8.dll
Re: ATTN Harold Hunt - Re: https no longer supported with wget v1.10.1
Got it... One question though: when you built it, was it statically linking the ssl libs? When I just rebuilt it, it statically linked them... which makes me think that the openssl install dependency is wrong, since I'm pretty sure there aren't any config files needed from the openssl package and the dynamic libraries, by definition, aren't needed for statically linked apps... What do you think? Harold Hack Kampbjorn wrote: Kelly Bagnell wrote: Why is https no longer supported with wget v1.10.1 It seems the new wget maintainer did not have openssl-devel installed when he packaged the new wget version. - GNU Wget 1.9.1 Copyright (C) 2003 Free Software Foundation, Inc. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Originally written by Hrvoje Niksic [EMAIL PROTECTED]. [EMAIL PROTECTED] smc]$ wget --output-document=https.html https://www.cygwin.com --00:03:43-- https://www.cygwin.com/ = `https.html' Resolving www.cygwin.com... 12.107.209.250 - GNU Wget 1.10.1 Copyright (C) 2005 Free Software Foundation, Inc. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Originally written by Hrvoje Niksic [EMAIL PROTECTED]. K2 wget --output-document=https.html https://www.cygwin.com https://www.cygwin.com: Unsupported scheme. -
Please upload: wget-1.10.1-1
First release after maintainer change: Files = http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.1-1.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.1-1-src.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/wget/setup.hint Changes === 2005-09-06 Harold L Hunt II - update to version 1.10.1 noteable: * supports files larger than 2GB * NTLM authentication supported * no longer truncates partial downloads * lots of SSL/TLS changes * 'wget -b' works correctly under Windows - update to latest generic-build-script - remove patch to ftp-basic.c that is now included upstream - Maintainer changed from Hack Kampbjørn to Harold L Hunt II Harold setup.hint == sdesc: Utility to retrieve files from the WWW via HTTP and FTP ldesc: GNU Wget is a file retrieval utility which can use either the HTTP, HTTPS, or FTP protocols. Wget features include the ability to work in the background while you're logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability. category: Web requires: openssl libintl3 libiconv2 bash cygwin
Re: 1st summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
Hack! I rerolled wget with the latest version that supports 2 GB files, and offerred to accept maintainership if you didn't want it anymore: http://cygwin.com/ml/cygwin-apps/2005-09/msg00074.html Chris said to await a response from you: http://cygwin.com/ml/cygwin-apps/2005-09/msg00075.html So, could you respond to that please? Thanks. Harold Hack Kampbjorn wrote: Hack Kampbjorn: keychain ncftp wget But my last windows computer at home is being hit by a deathstar battle station. And I will don't read cygwin mail at work even that I do have a windows desktop there where I use cygwin everyday.
Re: [HEADSUP] ALL Maintainers, please reply.
Corinna Vinschen wrote: Guys, On Sep 15 19:50, Yaakov S wrote: Harold L Hunt II wrote: Yaakov S wrote: I've already built 2.1.9 in order to run the current GIMP, so if you're not interested in updating this one, please let us know. It's yours. Accepted. I'll have an update out in the next few days. are you aware what you're doing here? How should anyone follow which package belongs to whom if you discuss moving packages around all the time? It's nice that you care but it would be nice for the sake of bookkeeping, if all maintainers who have given away and who have taken over a package at this point, could please send their updated lists of packages again. Hey, chill out, I have six weeks to send in my official list, now don't I? :) I'm going to send a final updated list for myself when my list has settled down a bit. It seems that lesstif, nedit, fontconfig, freetype, and libXft might all be going away, but I need to let all of those get worked out before I update my list. But, thanks for the headsup, because I wasn't thinking about updating the list until you mentioned it :) Harold
Re: lesstif
Hold up... am I not reading something correctly? Was the binutils change that caused the problem ever reverted? If not, the problem will still exist. I never heard that the change was reverted, so I'm wondering why binutils being up to date matters at all. IIRC, with the binutils change in place, the only way to address the issue would be to change nedit to no longer do a relocs in now-non-writable data, which would probably take a week. I seem to recall that I did everything you asked and it had some new problem (which I think was a crash on opening a file, or some such) so I decided to set it aside for a few days and promptly forgot about it. Look, the history doesn't matter. The point here is that I won't let someone release a version of lesstif that breaks nedit... now, if you're sure that nedit works just fine with your new lesstif build, then that's the end of the story, and we can stop trying to resurrect a conversation history. But, I mentioned that I would *like* you to do one more thing, which is to install nedit and lesstif on a machine that has no other modifications from you and just make sure that nedit still works and that you can actually open files; this might take 15 minutes, which is less time then we've spent talking about it. If it works, fine, proceed... if it doesn't work, fine, but proceed with caution and don't post a new 'curr' release of lesstif until you've fixed the problem with nedit. Deal? Harold Brian Ford wrote: On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Brian Ford Sent: 15 September 2005 23:20 I am confused, though. The crash you presented to me was one of not being able to start nedit at all: Date: Fri, 01 Jul 2005 17:09:32 -0700 From: Harold L Hunt To: Brian.Ford Subject: Re: lesstif update request Nope, 0.94.4 doesn't work with nedit: --- nedit.exe - Application Error --- The application failed to initialize properly (0xc005). Click on OK to terminate the application. That was the binutils relocs-in-non-writable-.rodata sections problem, wasn't it? Exactly, and I explained that to Harold in this not-yet-quoted private message from the thread in July (heavily snipped to be concise): Date: Tue, 05 Jul 2005 13:11:30 -0700 From: Harold L Hunt To: Brian Ford Subject: Re: lesstif update request On Fri, 1 Jul 2005, Harold L Hunt wrote: The application failed to initialize properly (0xc005). Click on OK to terminate the application. Looks like this could be caused by gcc = 3.3.3 putting const variables containing addresses of imported DLL symbols into .rdata (which then can't be magically relocated at run time since they end up in a read only section) as discussed here: http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html That was a libtool specific example, but I believe the problem is a general one. Yup, that sounds like it describes the problem... and I remember reading that thread a while back, but I guess I didn't catch the connection. [end quoted message] This is exactly why I suspected it was a problem with his binutils or gcc packages being out-of-date. It is also why I am so confused about him saying I need to play around with nedit to make it crash?
Re: lesstif
Brian, Brian Ford wrote: On Thu, 15 Sep 2005, Harold L Hunt II wrote: Brian Ford wrote: On Thu, 15 Sep 2005, Harold L Hunt II wrote: [snip] That's pretty much why the lesstif package is stuck where it is: it didn't work with nedit. We must have a mis-communication here. I told you (as quoted below) that my build of your unmodified lesstif-0.94.4 package worked for all our in-house applications as well as nedit. I suspected that you were using an outdated compiler or binutils package, and that was what caused your nedit issue. Hmm... no, I confirmed back, I believe, that I had the latest compiler and binutils and I think we left it at that. Since there is confusion about what is on both of our machines, the best thing for you to do would be to take a clean Windows image under VMWare, install Cygwin on it, compile the two packages and see what happens. Make sure that you do more with nedit than just opening it up... you actually need to open some files and play around in order to get it to crash (sometimes). Do you want to look into this, or do you just want to give lesstif to me? If you agree to some sort of verification that nedit works, its yours. No need to reply back, just take it if you agree. Harold No need to CC me in replies Hunt
libungif [Was: Re: [HEADSUP] ALL Maintainers, please reply.]
Lapo, Lapo Luchini wrote: Corinna Vinschen wrote: [snip] libungifAFAIR is should be Harold's since 4.1.0-3 Lapo Hmm... Here is me announcing a 4.1.2-1 for your eval: http://www.cygwin.com/ml/cygwin-apps/2004-03/msg00044.html Here is a response from you about how you think that I might be better suited to determine when it is ready for prime time: http://www.cygwin.com/ml/cygwin-apps/2004-03/msg00163.html Here is what we did with 4.1.2-1 and designation of a maintainer: [silence, crickets, leaves blowing around...] :) Looks like 4.1.2-1 got dropped on the floor since it is still marked as test almost 18 months later. The README for both versions still lists you as the maintainer. At this time I'd have to say that it doesn't make a lot of sense for me to become the maintainer, but I'd pick it up if the alternative was that it would be removed from the distro. Harold
Re: [HEADSUP] ALL Maintainers, please reply.
Sorry, I sent this earlier today, but from the wrong account so it ended up bouncing. Yaakov S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: Harold L Hunt II wrote: [...package list...] freetype? Indeed, freetype2 is somewhat out of date. I've already built 2.1.9 in order to run the current GIMP, so if you're not interested in updating this one, please let us know. It's yours.
[HELPFULL-REROLL] wget-1.10.1
I've been downloading lots of DVD ISO files of linux distributions lately (around 4 GB in size) and got burned a couple of times because wget did not support files larger than 2 GB; the behavior when a file was larger than 2 GB gave some false hope that perhaps the UI portion of wget couldn't handle greater than 2 GB but that the saving of the file might actually be fine. I downloaded several corrupt files 2 GB until I did some searching and confirmed that wget did not support files this large but that some work was underway to fix this. Of course, wget is useful on files 2 GB due to wget -c, which will continue an aborted download for you. Yesterday I did a search and found that wget had released version 1.10.1, which added support for files larger than 2 GB and they specifically mentioned that this worked on Windows (they didn't say Cygwin though, so I assume MinGW) as well. Because I needed this support for files larger than 2 GB badly, I decided to reroll the Cygwin package so that I could start using it immediately. I took Hack's current package, replaced the build script with the gbs (plus the @VERSION@/@REL@ replacement sed job), removed a patch that was included upstream now, packaged it, and tested it with a 4 GB file, which worked great. I am posting this package since it was useful to me and will probably be useful to others. I'm fine if Hack wishes to use it as his next release, use it as motivation to create his own next release, or ignore it completely. In the meantime, you can point setup.exe at: http://homer.starnet.com/~hunth/cygwin/ The package files can be downloaded here: http://homer.starnet.com/~hunth/cygwin/release/wget/setup.hint http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.1-1.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/wget/wget-1.10.1-1-src.tar.bz2 Oh, one nice thing is that the source package is 35% smaller since I bzip2'd the original source instead of leaving it gzipped. Well, I'll just wait until someone lets me know if they want to post this update or if something else is going to happen instead. Harold setup.hint == NOTE: This is the file from the web, which has bash as a dep instead of ash as the file in the source package had. sdesc: Utility to retrieve files from the WWW via HTTP and FTP ldesc: GNU Wget is a file retrieval utility which can use either the HTTP, HTTPS, or FTP protocols. Wget features include the ability to work in the background while you're logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability. category: Web requires: openssl libintl3 libiconv2 bash cygwin
Re: kuser-admin rsponse to cygwin-announce posts
I used to get them all the time as well, then I setup a special filter in my mail. I sent numerous messages to that host trying to get a human to look at the problem, but never received any reply. Very annoying. Harold Corinna Vinschen wrote: On Aug 4 16:47, Corinna Vinschen wrote: On Aug 4 14:27, Eric Blake wrote: Is it just me, or does every maintainer who sends mail to cygwin-announce get a spam from Kuser-admin AT kde.gr.jp, Subject: Subscribe request result (Kuser ML) Is there a way to unsubsribe this spammer from the announce list? I never got a mail from this address within the reach of my mail backlog (four months). The address is also not subscribed, just a kuser-ctl at the above domain. I got exactly one posting from that address back in May. I'm not sure that qualifies as spamming... Oh, sure, I'm using a write-only mail address, that's why I don't see them. If more than two maintainers get these mails all the time, I'll unsubscribe kuser-ctl. Corinna
Please upload: WindowMaker-0.90.0-2
http://homer.starnet.com/~hunth/cygwin/release/X11/WindowMaker/WindowMaker-0.90.0-2.tar.bz2 http://homer.starnet.com/~hunth/cygwin/release/X11/WindowMaker/WindowMaker-0.90.0-2-src.tar.bz2 (Yes, the setup.hint has been updated, please be sure to get it too) http://homer.starnet.com/~hunth/cygwin/release/X11/WindowMaker/setup.hint Harold
Re: [PATCH] generic-build-script
Max Bowsher wrote:
[...]
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG}
is used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[...]
Max,
My two cents:
Stick a comment above the definition for BASEPKG to explain the scenario
where BASEPKG and PKG-VER will be different... otherwise you'll get
dorks like me thinking that a patch reversing your patch would be
useful, and such a thing must just slip in by accident. Of course, the
comment would also help maintainers figure out that this feature is
present and that they can use it.
Since I've not written three times more words that would be in such a
comment, I might as well give it a go:
# NOTE: BASEPKG is name-version of the upstream package. Usually this
# is equal to ${PKG}-${VER}, except in the case where the Cygwin package
# name is different than the upstream package name (e.g. upstream:
# foo-1.0 BASEPKG=foo-1.0, Cygwin package: bar-1.0 PKG=bar VER=1.0).
Feel free to reword that.
Harold
Re: [PATCH] generic-build-script
s/Since I've not/Since I've now/ Harold Harold L Hunt II wrote: Since I've not written three times more words that would be in such a comment, I might as well give it a go:
Re: Please upload xmon-1.5.6-1 (new package)
Christopher Faylor wrote: On Fri, Jun 10, 2005 at 10:38:36AM -0700, Harold L Hunt II wrote: Christopher Faylor wrote: On Fri, Jun 10, 2005 at 02:14:16AM -0700, Harold L Hunt II wrote: I packaged the xmon program today (and used it extensively, so I know it works) for Cygwin. I took the liberty of checking Debian and see that this is a standard package there, so there is no need to vote on this. Thanks, I wasn't sure what the current rules were. Glad it was in Debian. But, where's the setup.hint file? Uhh... I hope I'm not misunderstanding the question... but, in the original email?!? http://homer.starnet.com/~hunth/cygwin/release/X11/xmon/setup.hint 7ab56809ff065a5e46693f49a1099f84 From http://cygwin.com/setup.html Submitting a package So you've got a package you want to submit. Follow the following checklist before emailing cygwin-apps@cygwin.com and you'll almost certainly save time. 1. Propose on cygwin-apps that you are interested in becoming a package maintainer for package foo. Some packages cannot be distributed via cygwin's setup due to vendor licence limitations. Other packages may not be appropriate for cygwin. This step will save time if, for some reason we cannot accept the package. 2. If this is a new package, *post a complete setup.hint file as part of your proposal*. Include this file in the text of your message so that it can be commented on. Do not submit it as an attachment. Are we posting or quoting rules? I have no interest in pedantics. Harold
Re: Please upload xmon-1.5.6-1 (new package)
Christopher Faylor wrote: On Sat, Jun 11, 2005 at 12:35:50PM -0400, Christopher Faylor wrote: On Sat, Jun 11, 2005 at 11:32:40AM -0400, Christopher Faylor wrote: On Fri, Jun 10, 2005 at 11:44:09PM -0700, Harold L Hunt II wrote: Christopher Faylor wrote: On Fri, Jun 10, 2005 at 10:38:36AM -0700, Harold L Hunt II wrote: Christopher Faylor wrote: On Fri, Jun 10, 2005 at 02:14:16AM -0700, Harold L Hunt II wrote: I packaged the xmon program today (and used it extensively, so I know it works) for Cygwin. I took the liberty of checking Debian and see that this is a standard package there, so there is no need to vote on this. Thanks, I wasn't sure what the current rules were. Glad it was in Debian. But, where's the setup.hint file? Uhh... I hope I'm not misunderstanding the question... but, in the original email?!? http://homer.starnet.com/~hunth/cygwin/release/X11/xmon/setup.hint 7ab56809ff065a5e46693f49a1099f84 From http://cygwin.com/setup.html Submitting a package So you've got a package you want to submit. Follow the following checklist before emailing cygwin-apps@cygwin.com and you'll almost certainly save time. 1. Propose on cygwin-apps that you are interested in becoming a package maintainer for package foo. Some packages cannot be distributed via cygwin's setup due to vendor licence limitations. Other packages may not be appropriate for cygwin. This step will save time if, for some reason we cannot accept the package. 2. If this is a new package, *post a complete setup.hint file as part of your proposal*. Include this file in the text of your message so that it can be commented on. Do not submit it as an attachment. Are we posting or quoting rules? I have no interest in pedantics. You asked why I was asking about the setup.hint file. This is why. I didn't see any obvious reason why I should refrain from pointing out the rules to you since I and others do that whenever someone sends an incomplete ITP here. sdesc: An interactive X protocol monitor ldesc: Xmon interactively monitors the byte-stream connections between an X server and a number of X clients. Xmon recognises all requests, events, errors and replies sent between the clients and the server which are part of the core X protocol. The contents of these messages are displayed on standard output at a user settable degree of detail from none to every bit and byte. category: X11 requires: cygwin xorg-x11-bin-dlls There is no need to include requires: cygwin. That's a given. Nope. Nevermind. I was wrong. I thought upset adds this automatically but it doesn't. I've uploaded this package. Thanks. Sending announcement now. Harold
Please upload xmon-1.5.6-1 (new package)
I packaged the xmon program today (and used it extensively, so I know it works) for Cygwin. Homepage http://www.x.org/contrib/devel_tools/ Description === http://www.x.org/contrib/devel_tools/xmon.1.5.6.README Xmon interactively monitors the byte-stream connections between an X server and a number of X clients. Xmon recognizes all requests, events, errors and replies sent between the clients and the server which are part of the core X protocol. The contents of these messages are displayed on standard output at a user settable degree of detail from none to every bit and byte. Xmon also allows the user to select a number of requests or events to be monitored at a different degree of detail. Xmon will also block the transmission of selected requests from the clients to the server and selected events from the server to the clients. Xmon also keeps statistics of the number of requests, events, and errors received. Porting === 1) The usual Imakefile stuff (two lines). 2) Two #define changes to make sure we call fcntl(*, FD_CLOEXEC) instead of ioctl(*, FIOCLEX, *), since FIOCLEX didn't seem to be available for ioctl (didn't check any further since I knew that FD_CLOEXEC was available and the code was already written for it. In summary, very straight-forward port and package. http://homer.starnet.com/~hunth/cygwin/release/X11/xmon/setup.hint 7ab56809ff065a5e46693f49a1099f84 http://homer.starnet.com/~hunth/cygwin/release/X11/xmon/xmon-1.5.6-1.tar.bz2 3664fa042a698104a9170cecb12cb8e5 http://homer.starnet.com/~hunth/cygwin/release/X11/xmon/xmon-1.5.6-1-src.tar.bz2 21998fb605d755857e7211b1febd4b99 Harold
Re: Please upload xmon-1.5.6-1 (new package)
Christopher Faylor wrote: On Fri, Jun 10, 2005 at 02:14:16AM -0700, Harold L Hunt II wrote: I packaged the xmon program today (and used it extensively, so I know it works) for Cygwin. I took the liberty of checking Debian and see that this is a standard package there, so there is no need to vote on this. Thanks, I wasn't sure what the current rules were. Glad it was in Debian. But, where's the setup.hint file? Uhh... I hope I'm not misunderstanding the question... but, in the original email?!? http://homer.starnet.com/~hunth/cygwin/release/X11/xmon/setup.hint 7ab56809ff065a5e46693f49a1099f84 Harold
Please upload: xterm-202
http://homer.starnet.com/~hunth/cygwin/release/X11/xterm/setup.hint (unchanged) http://homer.starnet.com/~hunth/cygwin/release/X11/xterm/xterm-202-1.tar.bz2 ed44f5b81dfda95bf4f3a4a330e30445 http://homer.starnet.com/~hunth/cygwin/release/X11/xterm/xterm-202-1-src.tar.bz2 eee866895118a4b9af5ed040099ffed0 It's been about seven months, so lets give this a try and see how it goes. Harold
Please upload distcc-2.18.3-1
http://homer.starnet.com/~hunth/cygwin/release/distcc/setup.hint (unchanged) http://homer.starnet.com/~hunth/cygwin/release/distcc/distcc-2.18.3-1.tar.bz2 c5b9509fb5dfd30d2d76d3846832d771 http://homer.starnet.com/~hunth/cygwin/release/distcc/distcc-2.18.3-1-src.tar.bz2 134a64b97ea4613bba3bf0a42fd61856 On a side note, I don't have distcc setup right now, so this release is untested... I would greatly appreciate it if someone that uses distcc took five minutes to try out this version and give an up/down report. For your convenience, there is a setup.ini at the following url, so you can just point setup.exe to it: http://homer.starnet.com/~hunth/cygwin/ [Watch out though, it'll upgrade your xterm too :) ] Harold
Re: Please upload distcc-2.18.3-1
I should clarify my intentions: I think this should be uploaded now and allowed to be curr. If there are problems, I'll fix them immediately, and the sooner that somebody gives a positive or negative review, the better I will feel. However, I don't think we should wait for a positive or negative review to post this, since it is all minor bug fixes and extremely unlikely to break anything. Harold Harold L Hunt II wrote: http://homer.starnet.com/~hunth/cygwin/release/distcc/setup.hint (unchanged) http://homer.starnet.com/~hunth/cygwin/release/distcc/distcc-2.18.3-1.tar.bz2 c5b9509fb5dfd30d2d76d3846832d771 http://homer.starnet.com/~hunth/cygwin/release/distcc/distcc-2.18.3-1-src.tar.bz2 134a64b97ea4613bba3bf0a42fd61856 On a side note, I don't have distcc setup right now, so this release is untested... I would greatly appreciate it if someone that uses distcc took five minutes to try out this version and give an up/down report. For your convenience, there is a setup.ini at the following url, so you can just point setup.exe to it: http://homer.starnet.com/~hunth/cygwin/ [Watch out though, it'll upgrade your xterm too :) ] Harold
Re: State of ddd and cygipc package
Corinna Vinschen wrote: On May 23 18:50, Corinna Vinschen wrote: On May 23 09:41, Harold L Hunt II wrote: Was there something specific you saw indicating that cygipc was still being used? If it is the setup.hint, then the setup.hint is just out of date. It's the requires: line in setup.hint. Could you please send an updated version of setup.hint then? For now I have just removed the cygipc dependency from ddd and moved the cygipc package to _obsolete. It would be nice if you could take a look into ddd/setup.hint, though, to check if all dependencies are ok. Thanks Corinna. I'm pretty sure the dependencies are fine for now, but I'll take a look at them when I update to the most recent ddd, hopefully soon. Harold
Re: State of ddd and cygipc package
Corinna, I thought I did this already, have you double-checked that you have the absolute latest version of the ddd package and that something isn't horked with your installation? I was going to post new versions of some of my packages, but I no longer have direct upload access and I haven't got a good place to put packages for another uploader to grab. Does anyone have a recommendation for a free place to post packages? Harold Corinna Vinschen wrote: Since cygserver exists for quite some time now, I'm wondering why the ddd package still references cygipc. I'd like to ask the ddd maintainer to come up with a new package which just uses the cygserver IPC stuff instead of using cygipc. The next step would be to either move the cygipc package into the _obsolete (aka ZZZRemovedPackages) group, or remove it entirely. In case of cygipc I think that removing the package is the way to go. Thanks, Corinna
Re: State of ddd and cygipc package
Oh yeah, and: [EMAIL PROTECTED] ~ $ cygcheck ddd | grep cygipc [EMAIL PROTECTED] ~ $ Was there something specific you saw indicating that cygipc was still being used? If it is the setup.hint, then the setup.hint is just out of date. I went on a pretty thorough campaign to get rid of packages that were dependent upon cygipc sometime over a year ago, since it seemed to be mostly my packages that were dependent on cygipc. I don't recall giving up before fixing ddd :) Harold Corinna Vinschen wrote: Since cygserver exists for quite some time now, I'm wondering why the ddd package still references cygipc. I'd like to ask the ddd maintainer to come up with a new package which just uses the cygserver IPC stuff instead of using cygipc. The next step would be to either move the cygipc package into the _obsolete (aka ZZZRemovedPackages) group, or remove it entirely. In case of cygipc I think that removing the package is the way to go. Thanks, Corinna
Re: plea for better sdesc lines
Lets see, GraphicsMagick, ImageMagick, WindowMaker, ddd, fvwm, lesstif, libsmi (was that me?), nedit, openbox, transfig, xfig, xfig-lib, xgraph (me???), and xterm. About 14 of 21. Wow, looks like I'm the number-one offender. ;) Harold Brian Dessent wrote: This is a request to all package maintainers to please check your setup.hints for bogus 'sdesc' lines. As you know, this is the text that is displayed to the user when using setup. It should not begin with the name of the package, since setup displays it as $package: $sdesc. It should also be more descriptive than just the name of the package, because foo: Foo is almost useless to the user. Surely you can describe your package with a short phrase or sentence. I wrote a small script that tests for these things as well as packages that reference anything in ZZZRemovedPackages in their Requires. The output is below: GraphicsMagick: sdesc contains only name of package ImageMagick: sdesc contains only name of package WindowMaker: sdesc contains only name of package XmHTML: sdesc begins with name of package ddd: sdesc contains only name of package fvwm: sdesc contains only name of package lesstif: sdesc contains only name of package libsmi: sdesc contains only name of package man: sdesc begins with name of package nedit: sdesc contains only name of package openbox: sdesc contains only name of package opengl: sdesc begins with name of package postgresql: sdesc begins with name of package shutdown: sdesc begins with name of package tetex-x11: references removed package in 'requires' transfig: sdesc contains only name of package x2x: sdesc contains only name of package xfig: sdesc begins with name of package xfig-lib: sdesc begins with name of package xgraph: sdesc contains only name of package xterm: sdesc begins with name of package Brian
Re: Welcoming Brian Dessent as setup maintainer
Brian, I noticed one thing, perhaps this was intentional: the Just Me and DOS/text options stay at the bottom of the option group when you resize or maximize the setup window. It looks a little silly, but if that is the intent, then it is fine with me :) The addition of the manifest makes the gui look really nice. Thanks for the tip by the way, I used that idea to refresh the gui of an app I am working on. I had no idea it was that easy... Oh, as a side note, it is pretty hard to find what I am supposed to be testing in this snapshot release for two reasons: 1) The email subject was not changed, so I have to dig through welcoming... messages to find it the announcement 2) There were no changes mentioned in the announcement, just in the thread history, which means that I have to essentially study before I can test and verify that things seem okay. I suggest sending an email with a new subject, even for these snapshot releases, with a recap of changes. Harold Brian Dessent wrote: Max Bowsher wrote: Don't be sorry at all. :-) trunk is supposed to be under active development - I think that it is perfectly OK to commit first and then discuss for any non-controversial changes. Heh. Turns out I screwed up the button groups on the 'RootPage' dialog pretty bad. Just committed a fix, going to upload a new test version. If anyone is trying these test versions, please get the new one. To avoid confusion, it might be better to name the executable something that hints at it not being compiled from purely committed code. Perhaps setup-2.490M.exe (M for modified), or setup-2.490+.exe. http://cygwin.com/setup-snapshots/setup-2.494-alpha.exe That should connotate the level of bugginess to expect, no? :) Brian (testers wanted)
Setup - Hiding ZZZRemovedPackages?
Brian, Would it be possible to hide the ZZZRemovedPackages category when in Category view, without changing the dependency logic regarding this category? Also, would it be possible to sort this category to the bottom of the list in all other views and ignore it when calculating the width to use for the Categories column? Currently the Categories column is too wide and scrunches the Package column because of the length of the ZZZRemovedPackages category name. Harold
Re: Setup - Hiding ZZZRemovedPackages?
I concur with the checkbox approach to hiding them altogether. Much less complicated and provides a way out to weird users (whom are the most likely to complain ;) Harold Brian Dessent wrote: Harold L Hunt II wrote: Would it be possible to hide the ZZZRemovedPackages category when in Category view, without changing the dependency logic regarding this category? Yes, in fact I've been meaning to bring this up. In terms of the end user, there should be no reason at all for them to see those packages, and I think it would be a good idea in general to remove them from sight entirely. The only worry I have is that if someone still has an ancient version of a package installed, they would no longer see it even though it's installed. Of course, if they just ran setup and accepted all the defaults they would get the new version of the package, without having to see them to select them. But I do wonder about those users (and I know they're out there) that insist on running 3 year old versions of some packages. I was thinking about making it a checkbox at the bottom of the dialog, that said Hide obsolete packages and defaults to checked. If the user unchecks it they would get the same display they get now. Also, would it be possible to sort this category to the bottom of the list in all other views and ignore it when calculating the width to use for the Categories column? Currently the Categories column is too wide and scrunches the Package column because of the length of the ZZZRemovedPackages category name. That would be another way of doing it. I'm not sure how easy or hard it would be to make them sort down to the bottom though. And I'd prefer to get rid of them entirely. Brian
Re: Welcoming Brian Dessent as setup maintainer
Brian, My major pet peeve has always been that setup.exe doesn't do any sanity checks on mount points to ensure that they actually exist on disk before starting the install process. Of course, if a mount point points to the D: drive that has been removed, setup effectively untars the packages to /dev/null, which doesn't help much :) I propose this solution: 1) Check each mount point to see if it actually points somewhere valid. 2) If any mount points point to invalid locations. a) Present a dialog, listing the invalid mount points b) Ask the user if they wish to continue the installation anyway I think that 2b) is required because I may have a mount point for /foo that points to z: which isn't there because I'm not on the network, but that souldn't stop the installation from happening since /usr /bin /etc, et al are all valid. Of course, there is an alternative: 1) Check each mount point 2) Remove any mount point that points to an unavailable location 3) Bail if / is then undefined This would have the effect of removing an invalid /usr/bin mount point, allowing the installation to continue to the default / mount point, and ... pretty confusing, eh? Forget it, go with the first option. Harold
Re: screen
Andrew, I tried packaging screen a long time ago, and failed. I got it compiling, but it didn't work correctly. I seem to recall that it really didn't work at all. The major obstacle to porting screen is that you have to understand how Cygwin handles terminals, which I don't, but maybe you do. If you understand that, then it should be possible, but if not then I don't know what to tell you. I just did a search of my web spaces and my local machine and couldn't find any trace of my efforts for packaging screen. Sorry :( Harold [EMAIL PROTECTED] wrote: I'm going to try to build and package screen for Cygwin. It's such a useful program, I just have to try. screen 4.0.2 won't compile OOTB in Cygwin: gcc -c -I. -I.-g -O2 misc.c misc.c: In function `xsetenv': misc.c:619: error: too few arguments to function `setenv' make: *** [misc.o] Error 1 I haven't looked into trying to fix this yet, it may be quite simple. There are many references to a binary of screen 4.0.2 compiled for Cygwin, and a corresponding patch, available at http://www.fredlwm.hpg.ig.com.br/cygwin/screen/. But that page has gone dark, and I can't find a cached copy of it anywhere. If someone has the patch that was provided there, I'd appreciate it if you'd pass it along. If anyone else has tried and failed to build or package screen for Cygwin, or if you know anything else about the feasibility of this little project, I'd appreciate hearing from you. Andrew.
Re: Your nail works for me.
Can I get two more +1 votes? I'll take Gerrit's testing as a good to go. I'll fix additional problems that crop up later. Harold [EMAIL PROTECTED] wrote: Hello Harold, your nail works (if you can read this;) To test the direct SMTP mail with nail I have this in .mailrc in my home directory: set smtp=192.168.1.1 set asksub set askcc set askatend set record=/var/mail/sent set [EMAIL PROTECTED] set hostname=familiehaase.de Since the mail is arriving, it should be ok, howevre i don;t know if the mbox stuff works sinc e I use nail to simply get mail off to my SMTP and off the system. Gerrit --
gcc 3.3.3 builds corrupt lesstif-0.93.94
The lesstif package was last built and released (0.93.94) with gcc-3.3.1 (or earlier, not sure). Performing a rebuild of the lesstif source as released (or any lesstif version after that) results in a good build, but one that gives a status access violation *immediately* upon being loaded; that is, DllMain is not even correctly called. Has anyone else ran into libraries that fail to build correctly under gcc-3.3.3? How close are we to another gcc release for Cygwin (I'm hoping this just goes away)? Harold
[ITP] nail-11.11
nail, an enhanced mailx command http://nail.sourceforge.net/ sdesc: nail category: Mail requires: cygwin ldesc: An enhanced mailx command http://www.cse.msu.edu/~huntharo/cygwin/release/nail/setup.hint http://www.cse.msu.edu/~huntharo/cygwin/release/nail/nail-11.11-1.tar.bz2 http://www.cse.msu.edu/~huntharo/cygwin/release/nail/nail-11.11-1-src.tar.bz2 Caveat: I don't know how to use nail. I need someone that has experience with nail to setup an account and run it. If all is well then the package is probably good to go. Harold
Re: [ITP] email-2.3.0
Christopher Faylor wrote: [snip] Isn't there anyone out there who can perform the dead-simple act of packaging up nail for this purprose? Sorry, can't be done: nail has a file called aux.c... the apocalypse must be coming soon. Harold
Re: [ITP] email-2.3.0
Ross Smith II wrote: [snip] Also, given that http://cvs.sourceforge.net/viewcvs.py/nail/nail/README?rev=HEADview=markup states: On the other hand, I strongly discourage from porting nail to Windows and environments that make Windows look Unix-like; I won't accept any patches or suggestions that go in this direction. There are two major reasons for this: First, any port makes maintaining harder; there are always more work-arounds in the source, and introducing new features involves the question whether they will work an all supported platforms. The more different a platform behaves from, let's say, the common Unix way, the more hacks have to be made, costing human time that could otherwise have been used to enhance the software for Unix platforms. Windows is just not worth this, and here we are at the second point: Porting software to Windows encourages people to use -- that is: to buy -- Windows. It supports a company that is known to threaten Open Source software like nail. In short, porting nail (or similar free software) to Windows has an ill effect on that software. Don't do it. My general response to arguments like that is: fuck 'em. I'll port it just to be a thorn in the guys side. Harold
Re: Package Proposal: Xcoral
Charles R. Hardnett wrote: Hi, I would like to maintain the xcoral package. The source is found at http://xcoral.free.fr +1 from me. Harold
Re: [ITP] xpdf: An open source viewer for Portable Document Format (PDF) files
Dr. Volker Zell wrote: Hi I would like to contribute and maintain the xpdf package: * http://www.foolabs.com/xpdf/ (Homepage) * ftp://ftp.foolabs.com/pub/xpdf (Download location) +1 from me. Harold
Re: [ITP] mathomatic-11.3f-1
+1 vote from me. Harold
Re: cygwin 1.5.10: ImageMagick 6.0.3 binaries fail
Okay, it is fixed now. There is a 6.0.4 version that is posted. The release notes explain the source of the problem (read: me). In addition, I installed jasper, lcms, and libfpx so support for these was compiled in. ImageMagick doesn't seem to do anything with libwmf... is that correct? Harold
Re: cygwin 1.5.10: ImageMagick 6.0.3 binaries fail
Harold L Hunt II wrote: Okay, it is fixed now. There is a 6.0.4 version that is posted. The release notes explain the source of the problem (read: me). In addition, I installed jasper, lcms, and libfpx so support for these was compiled in. ImageMagick doesn't seem to do anything with libwmf... is that correct? Hmm... oh, I see: libwmf support is not built in unless --with-modules=yes is used. We have not been enabling module support in the past and I didn't enable it in this release so libwmf was ignored. Comments on whether we should be enabling modules? Harold
Re: cygwin 1.5.10: ImageMagick 6.0.3 binaries fail
Hey man, ease. I've got it on my to-do list but right now our new baby takes priority. If you could help me out by telling other people to chill out for another week or so I'd appreciate it. Thanks, Harold Chris January wrote: I just updated my cygwin and related apps to the latest versions using the setup.exe tool. Things seemed to be working fine before the update, but now I have trouble running any ImageMagick tools. For example, the following command and resulting error: $ convert a.jpg b.png assertion list_info != (LinkedListInfo *) NULL failed: file /home/harold/ports/ImageMagick/ImageMagick-6.0.3/magick/hashmap.c, line 1033 I've received this error with all of the ImageMagick binaries I've tried to run. Just thought I'd let people know and see if others out there get the same error. I've attached the output from cygcheck -s -v -r in case anyone needs to look at it. Can the ImageMagick maintainer (Harold) please take note of this as there has been a slew of messages in this vein? Maybe it's a packaging problem as it seems all the programs are failing this assertion. Chris J
Re: Missing dependancy for ghostscript
The real solution is that ghostscript needs to be rebuilt ASAP against the new xorg-x11-* packages, which are two major releases newer than the version that ghostscript was built against. Harold David Yerger wrote: Tried to do a pdf2ps, got missing libICE.dll message - Re-running installer and adding XFree86-lib-compat fixed it. HTH Dave Yerger
Typo in generic-build-script
There is the following in the gbs: if [ -z $MY_CFLAGS ]; then MY_CFLAGS=-O2 fi if [ -z $MY_CFLAGS ]; then MY_LDFLAGS= fi It appears that the second if should be testing '$MY_LDFLAGS', not '$MY_CFLAGS'. Harold
Re: Harold gone?
Chuck hit the nail on the head. I handed over control of Cygwin/X because I am no longer interested in it. On the other hand, I still use Cygwin proper to get things done, so I can't exactly just sit there if package foo is not yet available for Cygwin and I need it for something I am working on... I'll have to package and maintain it myself. So Chuck was right in guessing that I am not giving up my non-X packages, but I am giving up the Cygwin/X project and I don't want to work on the X Server anymore, that is all. Harold Charles Wilson wrote: Gerrit P. Haase wrote: Hm, Harold is gone... Who takes over all his packages? Dunno if Harold is gone as in shall never darken our door again. He just relinquished primary control over the cygwin-xfree project. He didn't say anything about giving up any of his other packages, nor that he would stop reading these lists. Now, it may be true that he IS going to give up all of his pkgs and leave the cygwin community -- but so far, he hasn't said that, or if he did I missed it. Let's not probate the will until we're sure he's kaput. -- Chuck
Re: [ITP] OpenSP-1.5.1-1
+1 from me. I've been dying to get OpenJade on Cygwin for years. However, I can't remember if it was OpenSP or OpenJade itself that gave compilation problems. In other words, have you finished the tough part yet, or was OpenSP easy? Harold Gerrit P. Haase wrote: Hello, I want to contribute/maintain OpenSP, version 1.5.1. Canonical homepage: http://openjade.sf.net/ Prerequisite for OpenJade. Monolithic tarball because it is a stable production release. In case the API/ABI changes I'll provide a library/runtime package with the DLL. setup.hint: sdesc: SGML parser, production release. ldesc: The OpenJade project provides a suite of tools and libraries for validating, processing and applying DSSSL (Document Style Semantics and Specification Language) style sheets to SGML and XML documents. requires: cygwin libintl2 libiconv2 http://anfaenger.de/cygwin/opensp/OpenSP-1.5.1-1.tar.bz2 http://anfaenger.de/cygwin/opensp/OpenSP-1.5.1-1-src.tar.bz2 http://anfaenger.de/cygwin/opensp/setup.hint Gerrit
Re: [ITP] cppunit-1.9.14
I'm pretty sure I have three votes now. I guess I'll get around to uploading the package in a week or two. :) Harold
Re: [ITP] cppunit-1.9.14
Yaakov Selkowitz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harold L Hunt II wrote: | I want to contribute/maintain cppunit. | Canonical website: http://cppunit.sourceforge.net/ Pro from me. Just need one more vote now. I've been using the package for creating unit tests, so I give it my own GTG review. Let's get that extra vote. Harold
[ITP] cppunit-1.9.14
I want to contribute/maintain cppunit. Canonical website: http://cppunit.sourceforge.net/ Package setup.hint: === sdesc: A C++ unit testing framework. It started its life as a port of JUnit to C++ by Michael Feathers. ldesc: CppUnit is a C++ unit testing framework. It started its life as a port of JUnit to C++ by Michael Feathers. requires: cygwin category: Devel Libs [NOTE: I do not believe that this package needs to be split up into several packages (e.g., lib, devel, etc.) since the primary purpose of this package is to be used at compile time by developers, not at run time by users and the installed library version only works with the corresponding headers and support files.] Download: === http://www.cse.msu.edu/~huntharo/cygwin/release/cppunit/cppunit-1.9.14-1.tar.bz2 http://www.cse.msu.edu/~huntharo/cygwin/release/cppunit/cppunit-1.9.14-1-src.tar.bz2 http://www.cse.msu.edu/~huntharo/cygwin/release/cppunit/setup.hint Harold
Heads up to XmHTML maintainer
XmHTML was in the 'XFree86' category, which is non-existant. I changed the setup.hint on sources.redhat.com and replaced the 'XFree86' category with the 'X11' category. Just wanted to let you know so the master setup.hint can be updated. Harold
Re: [ITP] (audiofile, libaudiofile0, libaudiofile-devel)-0.2.6-1
+1 from me. Harold
Re: [ITP] (esound, libesound0, libesound-devel)-0.2.34-1
+1 from me. Harold
Re: Do I need XFree86 now that XOrg-x11 is the default X-windowing system? (fwd)
Nicholas Wourms wrote: pechtcha wrote: Harold, I really hate to say this, but I told you so... :-D Yeah, this name change business is a bit of a pain. I hope that this whole X11 feud gets resolved eventually, so people can get back to harmony and cooperation rather then wasting energy and resources on maintaining separate forks. What are you talking about? David Dawes is having a good time working on XFree86 by himself and everyone else is working on the X.Org project; I don't see any energy being wasted at all. Reason this is on-topic: The name change didn't really matter since I waited to do it until a full release was made, at which point everyone would have to re-download all packages anyway. Okay, that's all the education about the X world that is on-topic for this list. Harold
Re: Two new categories created. Comment needed
Christopher Faylor wrote: Harold Hunt has just, without any discussion here, created two new categories. One is understandable and probably doesn't require discussion. I actually created ZZZRemovedPackages at least a month or more ago. As you mention, X11 was not created, it was a rename of XFree86. The other, more controversial addition is ZZZRemovedPackages. Harold has moved older XFree86 stuff into this directory. Does anyone have a problem with this new category? I think it's obvious what it is used for. The question is does it serve a useful purpose? Is the name sufficiently clear? Does it cause any side effects that may not be immediately obvious? I vote pro :) If it is decided that this is a good thing then it needs to be documented. I think it is a good interim solution since I don't see anyone stepping up to code *anything* in setup.exe or otherwise take charge of setup.exe [cue offended remark from Rob Collins after his last offended remark almost three weeks ago with still no action as far as I can tell, sorry Rob, but I wish you could be more honest with yourself about how much time you have]. A longer term solution would be a tag in setup.hint files that mark a package as removed, but this is insanely more complex. Barring a complete update to setup.exe to handle removed packages, I think we might want adjust the script that generates http://cygwin.com/packages/ to make it ignore packages in the ZZZRemovedPackages category, which will remove lots of clutter from the pages it generates. This is not essential however. Harold
Re: Two new categories created. Comment needed
Igor Pechtchanski wrote: On Wed, 7 Apr 2004, Christopher Faylor wrote: Harold Hunt has just, without any discussion here, created two new categories. One is understandable and probably doesn't require discussion. He's changed XFree86 to X11. Oddly enough, XFree86 isn't currently listed as a category in setup.html so I've added X11 to the list of supported packages. I think this is a good idea, as long as every package that uses X is in that category. This includes, IMO, things like grace, emacs, xfig, etc. I'd also put ghostscript-x11 there if it isn't already. Already done: find -name *.hint | xargs sed -i -e s/^\(category:.*\)XFree86\(.*\)/\1X11\2/ Note to all X package maintainers: modify your setup.hint source files and change catgory XFree86 to X11 so that you don't accidentally revert this change on your next upload. The other, more controversial addition is ZZZRemovedPackages. Harold has moved older XFree86 stuff into this directory. Does anyone have a problem with this new category? I think it's obvious what it is used for. The question is does it serve a useful purpose? Is the name sufficiently clear? Does it cause any side effects that may not be immediately obvious? If it is decided that this is a good thing then it needs to be documented. cgf I believe it's a good idea to have something like it. A few comments, though... First, I don't like the ZZZ prefix -- we can probably use some non-alphanumeric character that succeeds 'z' in the collation order, e.g., _. I don't care what it is as long as it shows up at the bottom of the category list. We can change it easily enough at any time with a simple script, since I have put all such packages in a single top-level directory: release/ZZZRemovedPackages. Of course, it would make sense to rename the directory if we rename the category... Second, it should be made clear in the documentation that no new package should have that category, unless it's an upgrade helper package. Heh heh... you'd think package creators would figure that out, but best not to leave it unsaid. And third, it would be useful if the removed packages kept their original categories, with this one prepended to the list (so that it would always be seen in the Categories column in all of the views). I *strongly* disagree. The main reason I created this category was that people couldn't see the short description of a removed package or were not reading it (partly due to setup.exe not being resizeable), so they were trying to install removed packages and complaining that they didn't gain anything from installing that package. I don't want these packages showing up in their original categories because they are just clutter. If you have a very strong reason for why this is necessary, lets here it. Not as important, but we can also shorten it to _Removed or something. Well, I debated shortness vs. being absolutely clear with the name. I don't see a reason to not have Packages on the end, as it fits just fine in all displays that I've seen it on so far. Harold
Re: Two new categories created. Comment needed
Robert Collins wrote: On Thu, 2004-04-08 at 06:38, Harold L Hunt II wrote: [cue offended remark from Rob Collins after his last offended remark almost three weeks ago with still no action as far as I can tell, sorry Rob, but I wish you could be more honest with yourself about how much time you have]. I didn't offer to code anything up three weeks ago. If you want offended remarks, try this: Read what I wrote and don't troll. Here a quote from your email for you, since you seem to have forgotten what you wrote: Starting April I have a new job with (hopefully) more personal time to do things like setup.exe. You didn't say anything about sorry kids, I'll just be applying patches from now on, I won't be coding anymore. You implied that you would be doing precisely what most people think the maintainer of setup.exe should be doing: coding, applying patches, and getting releases out the door. Coding is a read haring anyway, what I said in my email was [...] I don't see anyone stepping up to code *anything* in setup.exe or otherwise take charge of setup.exe [...], yeah, that part about taking charge is much more important to me than any coding. I offered to review patches - where are they? Why the hell would I send you a patch when you have been sitting on a pile of them for six months and haven't released a thing? You like suggesting to people that they perform an exercise in futility? Since you still won't recognize that you haven't got time to work on setup.exe and won't release it to be maintained by someone else, I'll tell you exactly what I think: I want setup.exe maintainership *revoked* from you since I feel you are failing in your duties, one of which is to hand over maintainership when you no longer have time. If there was a way to put this to a vote here I'd do it; unfortunately, I don't think we have such a voting system designated for such problems. Harold
Re: [ITP] XmHTML: A widget capable of displaying HTML 3.2 conforming text
I vote pro for XmHTML. I believe that means that it now has the required 3 votes and a good to go review. Harold
Re: [Cron cgf cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0]
Oops. Instead of deleting the old -8 package I deleted the new -9 package. That left -8 without a matching -8 man-src package. Fixed now. Harld Christopher Faylor wrote: - Forwarded message from Cron Daemon - From: (Cron Daemon) To: cgf Subject: Cron cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0 Date: 28 Mar 2004 22:20:10 - upset: *** warning package XFree86-html refers to non-existent external-source: XFree86-man - End forwarded message -
Re: setup.exe development stalled?
Christopher Faylor wrote: It seems like development for setup.exe is sort of stalled. I agree completely. At the very least, it would be nice to get out a new release which resized correctly. I know that the current implementation isn't perfect but I wonder if it is better than the alternative of having a new user a week sending in a suggestion that the browser should be resizeable. Can we release setup.exe as is and maybe think about revitalizing development somehow? It would be nice if all of the things that the parser understands were actually understand by the rest of the program. I would like to see this very much and think it is a wise decision. In six days there has been zero discussion of this. Does that mean that setup.exe maintainership is up for grabs? If so, I've got things that I need to start doing with setup.exe, so I would be very interested in taking responsibility for setup.exe. I have the time for it now as well, and a project I am working on will really need setup.exe to be more robust and reliable (such as not blindly and silently unpacking files to mount points that do not point to physical disk locations). I'll start working on setup.exe next week and see how the maintainership question develops. Harold
Re: emacs 21.2-13 available
Corinna Vinschen wrote: On Mar 16 14:54, Joe Buehler wrote: I haven't uploaded anything in a while so please let me know if there are any new requirements on the part of Cygwin package maintainers or packages... New GNU emacs package files are available at: http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-21.2-13-src.tar.bz2 http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-21.2-13.tar.bz2 http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-X11/emacs-X11-21.2-13.tar.bz2 http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-X11/setup.hint http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-ctags/emacs-ctags-21.2-13.tar.bz2 http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-el/emacs-el-21.2-13.tar.bz2 http://68.98.176.216:3000/cygwin/emacs-21.2-13/emacs-el/setup.hint http://68.98.176.216:3000/cygwin/emacs-21.2-13/setup.hint Changes: - recompile against latest XFree86 (the major reason for this release) - setup.hint changes due to rearrangements of various required runtime libraries - moved documentation from /usr/doc to /usr/share/doc Note that I'm not an emacs user so I can't tell if the binary works or not. These are just packaging observations: - The info pages are still in /usr/info, they should be in /usr/share/info. - Ditto for /usr/man vs. /usr/share/man. - Don't supply emacs-ctags. It conflicts with the ctags package which provides an emacs independent ctags (and etags). - The emacs-21.2-13.tar.bz2 as well as the emacs-X11/emacs-X11-21.2-13.tar.bz2 provide a /usr/bin/emacs.exe binary. So the emacs packages conflict with each other. I'd like to maintain the status quo for all of these to get this new version released as soon as possible. A -14 release can contain all of these fixes, and I agree that it should follow quickly. Harold
Re: emacs 21.2-13 available
Corinna Vinschen wrote: On Mar 18 14:54, Harold L Hunt II wrote: Corinna Vinschen wrote: - The info pages are still in /usr/info, they should be in /usr/share/info. - Ditto for /usr/man vs. /usr/share/man. - Don't supply emacs-ctags. It conflicts with the ctags package which provides an emacs independent ctags (and etags). - The emacs-21.2-13.tar.bz2 as well as the emacs-X11/emacs-X11-21.2-13.tar.bz2 provide a /usr/bin/emacs.exe binary. So the emacs packages conflict with each other. I'd like to maintain the status quo for all of these to get this new version released as soon as possible. A -14 release can contain all of these fixes, and I agree that it should follow quickly. I disagree. The above problems are showstoppers for me, most notably the conflict with ctags. And they aren't really difficult to fix. If they were really showstoppers then emacs would have been pulled from distribution long ago. It doesn't matter if they are critical, they won't make anything worse than waiting a few more days for another release would. Harold
Re: Busted generic build script?
Igor Pechtchanski wrote: On Thu, 18 Mar 2004, Harold L Hunt II wrote: [snip] Oops. Mea culpa. I've verified that it worked in bash, and ran the script through sh -n (which turns out to not be enough). Harold, could you please try the attached patch and see if it fixes things for you? If yes, I'll commit it to CVS. Igor Yes, the patch fixes the problem. Thanks, Harold
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
Lapo Luchini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harold L Hunt II wrote: I am posting this for review by Lapo, the current maintainer of libungif. If Lapo approves, I will upload this ASAP. I'm packagin' 4.1.1, but in the meantime feel free to upload this one (that seems to have already most of the needed patches except upgrade to latest version ^_^). Oops, I hadn't realized that you had given the okay to upload here. I just uploaded 4.1.0-3 as 'curr' and 4.1.2-1 as 'test', and pushed a new setup.hint that doesn't depend on XFree86-lib-compat. Let us know if/when 4.1.2-1 should be marked as 'curr' and 4.1.0-3 removed. Harold
[Un-ITP] ns, octl, tclcl [Was: Pending Packages List, 2004-03-13]
Package: otcl 1.0.9-1 [2003-10-29] Description: OTcl, short for MIT Object Tcl. (main package) Also: libotcl0 [OTcl, short for MIT Object Tcl. (runtime)] Also: libotcl-devel [OTcl, short for MIT Object Tcl. (development)] Proposal: http://cygwin.com/ml/cygwin-apps/2003-10/msg00419.html http://cygwin.com/ml/cygwin-apps/2003-10/msg00420.html Last review: http://cygwin.com/ml/cygwin-apps/2004-02/msg00032.html (GTG) HOLD-UPS: Package: tclcl 1.0.13-1 [2003-11-01] Description: TclCL (Tcl with classes) is a Tcl/C++ interface used by Mash, vic, vat, ... Also: libtclcl0 [TclCL (Tcl with classes). (runtime)] Also: libtclcl-devel [TclCL (Tcl with classes). (development)] Proposal: http://cygwin.com/ml/cygwin-apps/2003-11/msg5.html Last review: http://cygwin.com/ml/cygwin-apps/2004-02/msg00036.html (no go) http://cygwin.com/ml/cygwin-apps/2004-02/msg00037.html (no go) HOLD-UPS: Unresolved problems. No good to go review. ITP: ns [2003-10-18] Description: The Network Simulator - ns-2 Also: nam [The Network Animator - Nam] ITP: http://cygwin.com/ml/cygwin-apps/2003-10/msg00280.html HOLD-UPS: Missing 3 votes. No package, nothing to review! I don't have time to work on these anymore and my motivation for doing so has passed. Please remove them from the PPL until such a time that I (or someone else) might ITP them again. Harold
Heads Up: Cygwin/X no longer dependent on cygipc
I recompiled and posted a new build of the Cygwin/X package that were previously dependent on cygipc against cygserver instead. All setup.hint files for Cygwin/X packages and other X packages maintained by myself (not requiring a rebuild) have been updated to no longer require cygipc. I still need to update (rebuild required): *** GraphicsMagick *** libGraphicsMagick-devel *** libGraphicsMagick0 *** ImageMagick *** libMagick-devel *** libMagick6 Others need to update setup.hint's for (no rebuild required): *** gd *** libgd-devel *** libgd2 *** gnuplot *** gv *** xemacs Others need to rebuild: *** postgresql Looks like we are only 3 package rebuilds away from no longer requiring cygipc... not to say that it would be wise to immediately pull it from distribution, but at least we would be one step closer. Harold
xemacs - Package problem?
Correct me if I am wrong, but the 'xemacs' package is including the following file: /usr/bin/xemacs-21.4.15-4036492d.dmp (2855 KiB) It seems that this is nothing more than a crash dump file and that it mistakenly in the binary package file. Is that correct? If so, it should shave a considerable amount off of the 6 MiB xemacs binary package size. Harold
Re: xemacs - Package problem?
Hmm... definitely not a crash dump file Sorry for the noise. Harold Harold L Hunt II wrote: Correct me if I am wrong, but the 'xemacs' package is including the following file: /usr/bin/xemacs-21.4.15-4036492d.dmp (2855 KiB) It seems that this is nothing more than a crash dump file and that it mistakenly in the binary package file. Is that correct? If so, it should shave a considerable amount off of the 6 MiB xemacs binary package size. Harold
Re: Heads Up: cygwin/X no longer dependent on cygipc
Christopher Faylor wrote: On Tue, Mar 16, 2004 at 11:05:10PM -0500, Harold L Hunt II wrote: I recompiled and posted a new build of the Cygwin/X package that were previously dependent on cygipc against cygserver instead. All setup.hint files for Cygwin/X packages and other X packages maintained by myself (not requiring a rebuild) have been updated to no longer require cygipc. I still need to update (rebuild required): *** GraphicsMagick *** libGraphicsMagick-devel *** libGraphicsMagick0 *** ImageMagick *** libMagick-devel *** libMagick6 Others need to update setup.hint's for (no rebuild required): *** gd *** libgd-devel *** libgd2 *** gnuplot *** gv *** xemacs Others need to rebuild: *** postgresql Looks like we are only 3 package rebuilds away from no longer requiring cygipc... not to say that it would be wise to immediately pull it from distribution, but at least we would be one step closer. I find it hard to believe that all of the above packages actually directly rely on cygpic. I suspect that most of these are bypassing the rule of not including dependencies of packages from the Required line in setup.hint. So, most of the cygpic's (and probably a lot of other dependencies) should probably be dropped. All of the above? I only listed thee that need to be rebuilt because of direct dependencies on cygipc. The middle section says no rebuild required and need to update setup.hint's. I totally agree with you. :) Harold
Re: Heads Up: cygwin/X no longer dependent on cygipc
Dr. Volker Zell wrote: Christopher == Christopher Faylor writes: Others need to update setup.hint's for (no rebuild required): *** gd *** libgd-devel *** libgd2 *** gnuplot *** gv *** xemacs I think these are all mine ... Okay. Christopher I find it hard to believe that all of the above packages actually Christopher directly rely on cygpic. I suspect that most of these are bypassing the Christopher rule of not including dependencies of packages from the Required line Christopher in setup.hint. So, most of the cygpic's (and probably a lot of other Christopher dependencies) should probably be dropped. I'll check which ones actually rely on cygipc. My setup hints are generated with the help of Igors dependencies script. This script just picks up ALL dependent dlls and doesn't care if an executable is directly dependent on a another package or not. But I have a feeling that my packages don't directly depend on cygipc. I did a quick 'cygcheck' on each of those packages and saw two things that made me think that they do not directly depend on cygipc: 1) cygipc wasn't listed. 2) cygX11-6.dll was listed, which means that there would have been a false dependence on cygipc generated by this library before. Hope that helps. I think you can just update the setup.hint's for those packages. Harold
Re: *** warning package libXft1 refers to non-existent external-source: libXft
Oops, fixed it. Harold Christopher Faylor wrote: upset: *** warning package libXft1 refers to non-existent external-source: libXft Maybe upset just caught a snapshot of a work in progress but I'm forwarding this message along just in case since I'm going to bed. cgf
cygutils - mkshortcut - Patch for --desc option for description/tooltip text - Needed for new Cygwin/X package
Attached is a patch to mkshortcut to allow it to take a [-d|--desc] DESC
option that specifies the text of the description (tooltip text) for the
shortcut. If -d|--desc is not specified, then the previous behavior of
setting the description to the POSIX path to the application is used.
I have build tested and run tested the attached patch.
I need this patch for a replacement for the XFree86-bin-icons package.
I already have the new package in hand, but I need this new
functionality in order for the shortcuts to have meaningful names and
descriptions.
Harold
Index: mkshortcut/mkshortcut.1
===
RCS file: /cvs/cygwin-apps/cygutils/src/mkshortcut/mkshortcut.1,v
retrieving revision 1.5
diff -u -r1.5 mkshortcut.1
--- mkshortcut/mkshortcut.1 14 Feb 2004 23:34:57 - 1.5
+++ mkshortcut/mkshortcut.1 10 Mar 2004 18:43:03 -
@@ -1,6 +1,6 @@
.\{{{}}}
.\{{{ Title
-.TH MKSHORTCUT 1 21 Oct 03 mkshortcut 1.5 (cygutils) Cygutils
+.TH MKSHORTCUT 1 10 Mar 04 mkshortcut 1.6 (cygutils) Cygutils
.\}}}
.\{{{ Name
.SH NAME
@@ -10,7 +10,8 @@
.SH SYNOPSIS
.B mkshorcut
.RB [\-\fBa\fP \fIARGS\fP]
-.RB [\-\fBi\fP \fIiconfile\fP [\-\fBj\fP \fIINT\fP] ]
+.RB [\-\fBd\fP \fIDESC\fP]
+.RB [\-\fBi\fP \fIICONFILE\fP [\-\fBj\fP \fIINT\fP] ]
.RB [\-\fBn\fP \fINAME\fP ]
.RB [\-\fBs\fP \fInorm|min|max\fP ]
.RB [\-\fBw\fP \fIPATH\fP ]
@@ -23,6 +24,10 @@
.TP
\fB\-a\fR, \fB\-\-arguments\fP=\fIARGS\fP
Arguments to use (see example below).
+
+.TP
+\fB\-d\fR, \fB\-\-desc\fR=\fIDESC\fP
+Text for description/tooltip (defaults to POSIX path of TARGET). Note that
\fIDESC\fP can contain spaces, but in that case must be enclosed in quotes.
.TP
\fB\-h\fR, \fB\-\-help\fR
Index: mkshortcut/mkshortcut.c
===
RCS file: /cvs/cygwin-apps/cygutils/src/mkshortcut/mkshortcut.c,v
retrieving revision 1.6
diff -u -r1.6 mkshortcut.c
--- mkshortcut/mkshortcut.c 14 Feb 2004 23:34:57 - 1.6
+++ mkshortcut/mkshortcut.c 10 Mar 2004 18:43:03 -
@@ -61,6 +61,7 @@
int show_flag;
int offset;
char * name_arg;
+ char * desc_arg;
char * dir_name_arg;
char * argument_arg;
char * target_arg;
@@ -93,7 +94,7 @@
const char * arg;
struct poptOption helpOptionsTable[] = {
-{ help, 'h', POPT_ARG_NONE, NULL, '?', \
+{ help, 'h', POPT_ARG_NONE, NULL, '?', \
Show this help message, NULL},
{ usage, '\0', POPT_ARG_NONE, NULL, 'u', \
Display brief usage message, NULL},
@@ -105,24 +106,26 @@
};
struct poptOption generalOptionsTable[] = {
-{ arguments, 'a', POPT_ARG_STRING, NULL, 'a', \
+{ arguments, 'a', POPT_ARG_STRING, NULL, 'a', \
Use arguments ARGS, ARGS},
+{ desc, 'd', POPT_ARG_STRING, NULL, 'd', \
+Text for description/tooltip (defaults to POSIX path of TARGET), DESC},
{ icon, 'i', POPT_ARG_STRING, NULL, 'i', \
-icon file for link to use, iconfile},
+Icon file for link to use, ICONFILE},
{ iconoffset, 'j', POPT_ARG_INT, (opts.offset), 'j', \
-offset of icon in icon file (default is 0), NULL},
+Offset of icon in icon file (default is 0), NULL},
{ name, 'n', POPT_ARG_STRING, NULL, 'n', \
-name for link (defaults to TARGET), NAME},
+Name for link (defaults to TARGET), NAME},
{ show, 's', POPT_ARG_STRING, NULL, 's', \
-window to show: normal, minimized, maximized, norm|min|max},
+Window to show: normal, minimized, maximized, norm|min|max},
{ workingdir, 'w', POPT_ARG_STRING, NULL, 'w', \
-set working directory (defaults to directory path of TARGET), PATH},
+Set working directory (defaults to directory path of TARGET), PATH},
{ allusers, 'A', POPT_ARG_VAL, (opts.allusers_flag), 1, \
-use 'All Users' instead of current user for -D,-P, NULL},
+Use 'All Users' instead of current user for -D,-P, NULL},
{ desktop, 'D', POPT_ARG_VAL, (opts.desktop_flag), 1, \
-create link relative to 'Desktop' directory, NULL},
+Create link relative to 'Desktop' directory, NULL},
{ smprograms, 'P', POPT_ARG_VAL, (opts.smprograms_flag), 1, \
-create link relative to Start Menu 'Programs' directory, NULL},
+Create link relative to Start Menu 'Programs' directory, NULL},
{ NULL, '\0', 0, NULL, 0, NULL, NULL }
};
@@ -161,6 +164,7 @@
opts.target_arg = NULL;
opts.argument_arg = NULL;
opts.name_arg = NULL;
+ opts.desc_arg = NULL;
opts.dir_name_arg = NULL;
opts.icon_name_arg = NULL;
@@ -177,6 +181,14 @@
goto exit;
case 'l': license(optCon, stderr, program_name);
goto exit;
+ case 'd': if (arg = poptGetOptArg(optCon)) {
+ if ((opts.desc_arg = strdup(arg)) == NULL ) {
+ fprintf(stderr, %s: memory allocation error\n, program_name);
+
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
Lapo, Lapo Luchini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harold L Hunt II wrote: I am posting this for review by Lapo, the current maintainer of libungif. If Lapo approves, I will upload this ASAP. I'm packagin' 4.1.1, but in the meantime feel free to upload this one (that seems to have already most of the needed patches except upgrade to latest version ^_^). 2) Added dependency on XFree86-bin in setup.hint. (Harold L Hunt II) Actually I was thinking about using --without-x in next release. But no other program seems to use it, except WMaker, that uses X11 anyway. 4) Fixed build script to ignore files generated by relibtoolize, since this step will be performed on next rebuild. (Harold L Hunt II) I also knida changed my idea to ease the work on the user by including the giga-patch instead of dynamic relibtoolizing. But I doubt that user really exists, and relibtoolizing works just as good, with a much clearer patch. Actually, I did package 4.1.2 (released a few days ago) and posted it for your review also: http://cygwin.com/ml/cygwin-apps/2004-03/msg00044.html It is ready to upload and does the proper amount of re-autotooling before building and properly ignores those generated files. There doesn't seem to be a reason to do --without-x since libungif has used it for two years without major problems. Harold
Re: emacs / libICE.dll
Corinna Vinschen wrote: On Mar 9 14:03, Oodini wrote: Hello, I've just installed Cygwin on Windows 2000 to learn Unix stuff, and I don't succeed to run emacs. Windows looks for the missing dll libICE.dll. Please note that I don't know Unix, except some basic command. Thanks for help. Wrong mailing list. Try Well, sort of, but we need to discuss this here as well. I have been telling people that the lib*.dll libraries for Cygwin/X would be going away for a few months now and apparently the emacs maintainer has not had a chance to recompile their package in 8 months. emacs really needs to get rebuilt since I will be pulling thos lib*.dll libraries from the distribution within the next week or so. On a side note, emacs must have been missing XFree86-lib-compat as dependency in setup.hint for about 8 months now; this would explain why this user does not have those libraries. Harold
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
Frédéric L. W. Meunier wrote: Sorry, sent it to cygwin-xfree. Time to sleep. On Tue, 9 Mar 2004, Harold L Hunt II wrote: Lapo Luchini wrote: Actually I was thinking about using --without-x in next release. But no other program seems to use it, except WMaker, that uses X11 anyway. There doesn't seem to be a reason to do --without-x since libungif has used it for two years without major problems. These aren't really strong arguments. Lapo is assuming that only WindowMaker uses libungif because it's the only application linked to it in Cygwin. You're assuming libungif should depend on XFree86 because it worked fine with it for 2 years. linbugif compiled with --without-x will work fine too, and also enable other people who don't want to install XFree86 to use the library or any tools, except gif2x11. Okay, I will make a stronger argument: I will be really p'odd if a rebuild of libungif using --without-x busts my WindowMaker package. In fact, I don't even want to have to look into whether WindowMaker is busted or not; I want to maintain the status quo because I am too busy to do otherwise. If you rebuild libungif using --without-x, rebuild WindowMaker against that version of libungif, install both and test them to confirm that WindowMaker works, then I *might* think it is okay to use --without-x for libungif. This is simply following the rule of if it ain't broke, don't fix it. I often find out that lots of other people have plenty of arguments for leaving something alone when I cannot think of such an argument myself. Of course, I figure this out after the fact; in this case I am not interested in being unpleasantly surprised. But, again, is it so hard to make 2 packages, one with --without-x ? Have you done it? Yes, it is really hard. Think about 16 hours to work out all of the little kinks. Harold
libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
It was brought to my attention today that my WindowMaker package requires files in the XFree86-lib-compat package by its dependency on the libungif package. Note: I did not say that setup.exe knows about this dependency (that is another issue [1]). The libungif package was last updated on 2002/07/14. Since that time the X library naming scheme was changed and the libraries in the XFree86-lib-compat package are going to be pulled from distribution within a week or two. There was some discussion about updating the libungif package about a week ago but nothing has come of it yet. I have an interest in getting this fixed, so I have completed a rebuild of the package, fixing several errors that I discovered in the process. I have left the package as libungif-4.1.0 for now... the patches I made should also make the just released 4.1.2 package build fine (released 2004/03/02). I am posting this for review by Lapo, the current maintainer of libungif. If Lapo approves, I will upload this ASAP. Changes for libungif-4.1.0-3 1) Rebuild against current X libraries; old build required XFree86-lib-compat package, which will be pulled from distribution soon after 2004/03/05. (Harold L Hunt II) 2) Added dependency on XFree86-bin in setup.hint. (Harold L Hunt II) 3) Fixed build script to clean the autom4te.cache directory in 'mkpatch' step. (Harold L Hunt II) 4) Fixed build script to ignore files generated by relibtoolize, since this step will be performed on next rebuild. (Harold L Hunt II) 5) Moved relibtoolize from 'conf' step to 'prep' step so it will only be performed once. (Harold L Hunt II) 6) Update build script to autodetect original source file compression type. 7) Append $(EXEEXT) to COMPILABLE_EXTRAS in configure.in so that the defined build rules in utils/Makefile.am are used instead of default build rules (which results in certain includes not being found). (Harold L Hunt II) 8) Add -no-undefined to libunfig_la_LDFLAGS in lib/Makefile.am to enable building of a shared library (DLL). It doesn't seem that the patches described in the 4.1.0-2 release notes actually made it into the -src package. (Harold L Hunt II) 9) Move documentation from /usr/doc to /usr/share/doc and limit files copied to *.html, *.png, and *.txt. (Harold L Hunt II) 10) Fixed quoting issue in setup.hint that was fixed on sources.redhat.com but not in the source package. (Harold L Hunt II) Package for review == wget --non-verbose \ http://www.egr.msu.edu/~huntharo/cygwin/release/libungif/\ libungif-4.1.0-3-src.tar.bz2 \ http://www.egr.msu.edu/~huntharo/cygwin/release/libungif/\ libungif-4.1.0-3.tar.bz2 \ http://www.egr.msu.edu/~huntharo/cygwin/release/libungif/setup.hint I tested WindowMaker against this rebuild and it ran fine. I also checked the dependencies of wmaker.exe with cygcheck and noted that the dependency on libX11.dll was gone and replaced with cygX11-6.dll, which is as expected. Harold [1] Note: libungif-4.1.0-2, even though dependent upon files in XFree86-lib-compat, did not actually list that package as a dependency in its setup.hint; users that did not happen to have XFree86-lib-compat installed would get an error when libX11.dll could not be found and wmaker.exe would fail to run.
libungif-4.1.2-1 also available as 'test'
The patches I made worked for libungif-4.1.2 as well, so I packaged up libungif-4.1.2-1 as a 'test' package on my site. You can point Cygwin's setup.exe at the following address to install either 4.1.0-3 or 4.1.2-1: http://www.egr.msu.edu/~huntharo/cygwin/ Changes for libungif-4.1.2-1 from libungif-4.1.0-3 == 1) Sync with upstream 4.1.2 release. Package for review == wget --non-verbose \ http://www.egr.msu.edu/~huntharo/cygwin/release/libungif/\ libungif-4.1.2-1-src.tar.bz2 \ http://www.egr.msu.edu/~huntharo/cygwin/release/libungif/\ libungif-4.1.2-1.tar.bz2 \ http://www.egr.msu.edu/~huntharo/cygwin/release/libungif/setup.hint Again, this is for Lapo to review... he can do with it as he pleases; I just wanted to get the ball rolling. Harold
[Review - Not yet] aterm-0.4.2-1 - vt102 terminal emulator, based on rxvt
Jari, You have a dependency in setup.hint on 'cygipc2'. There is no such package, it is called 'cygipc'. You also have a dependency on 'xfree86-base'. Note that the package name is 'XFree86-base'. This should be fixed for consistency. Did you actually try to use this package? I ran it from and xterm and it didn't echo typed characters and printed escape sequences for the shell prompt instead of readable characters. It performed similarly from a command prompt. Launching from both an xterm and from the command prompt resulted in aterm using 100% of the CPU. Unless you tested this and these are minor and easily fixable problems, then I am going to actually ask you to revoke you ITP since there is no way that this package can be included with the above shell and infinite loop problems. Harold
[Review - Not yet] xbuffy-3.3.1.3-1 - X program to display unread mail
Jari, There is a dependency in setup.hint on 'cygipc2'. There is no such package, it is called 'cygipc'. There is a dependency on 'xfree86-base'. Note that the package name is 'XFree86-base'. This should be fixed for consistency. Some files are installed to /usr/lib/X11/app-defaults. This should instead go in /etc/X11/app-defaults and no /usr/lib/X11 directory should be created. I tested the program by pointing it to a mailbox file on a Linux machine via Samba and it worked fine. Should be ready for uploading when the above minor issues are addressed. Harold
Re: [Review - Not yet] aterm-0.4.2-1 - vt102 terminal emulator, based on rxvt
Igor Pechtchanski wrote: On Thu, 4 Mar 2004, Harold L Hunt II wrote: If aterm is based on rxvt, it probably runs /bin/sh rather than /bin/bash (which would explain the escape sequence problem above). The solution for rxvt (which should also help here) is to run rxvt -e bash. I agree that the other problems are pretty much showstoppers. It would have helped if you mentioned at least the version of Windows that you tried it on, though (I assume you have the latest packages installed). In the interest of not writing overly long emails (which I find people tend to ignore), I decided to not even mention that I tried other shells since describing the slight difference in behavior wouldn't really matter since it goes into an infinite loop. aterm -e /bin/bash behaves only slightly differently. The version of Windows I am running doesn't matter unless Jari can't reproduce the problem, in which case he can ask what version I have; until then it would just be noise. Harold
Re: [Review - Not yet] aterm-0.4.2-1 - vt102 terminal emulator, based on rxvt
Charles Wilson wrote: Harold L Hunt II wrote: You have a dependency in setup.hint on 'cygipc2'. There is no such package, it is called 'cygipc'. Also, any *new* packages, IMO, should not rely on cygipc at all. Instead, they should be compiled against cygserver, which beats the pants off cygipc any day of the week, and twice on Sunday. He is only dependent upon cygipc because Cygwin/X is dependent upon it and has not yet been rebuilt against cygserver. I have been waiting to do this rebuild until I release the new Cygwin/X build from the xorg tree on freedesktop.org. I am gearing up to do this... possibly next week as a sort of 1.0pre-1 release since the official 1.0 release won't be made for at least a few weeks. When I do that rebuild it will be against cygserver and cygipc will be dropped as a dependency. Harold
Re: update on packages with export considerations
Thank you for the clarification on what is happening. Harold Christopher Faylor wrote: I've asked our legal department to file the proper paperwork to enable us to provide the following packages: - GnuPG - ccrypt - zip/unzip with encryption They seem to be indicating that there is no problem doing any of the above (which isn't too surprising for GnuPG and zip/unzip at least) but I don't have a feel yet for how long this will take and don't remember from the last time we did this. Hopefully it won't be more than a week. FYI, cgf
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
Igor Pechtchanski wrote: XFree86-f*.sh: umount, cygpath, mount Note: the above script should also check that the directory is already mounted in the correct mode instead of unmounting and remounting it all the time. The reason we force an unmount is that the mount point may, in fact, by pointing to a non-existant path. That means that setup.exe will extract our package files to /dev/null on an attempt at a first install with an invalid font mount point. However, most users will then attempt a second install; without the forced unmount/remount, the same problem would recur. The forced unmount/remount causes the second and subsequent installation attempts to succeed. I would love to solve this problem properly but pre-install scripts would be a real challenge for setup.exe, unless there was a concise set of rules about what packages could and could not have pre-install scripts, lest we end up with chicken before egg problems for some packages. XFree86-lib.sh: mkdir, test?, tar, rm, ln XFree86-prog.sh: touch, ln XFree86-xserv.sh: ln fontconfig.sh: dirname, basename, diff, cp, mkdir Note: this one also uses bash syntax. Moreover, it requires things like diff and dirname/basename to run, but neither diffutils nor sh-utils are in the requires clause of fontconfig. freetype2.sh: mkdir, ln I agree that I should probably hand-craft the PATH for all of the above scripts (including the XFree86-f*.sh scripts). xfig.sh: mkdir, tar, rm, ln Note: tar should be required. Ditto. Interesting not about tar not being a required package. I never realized that that script used tar. In fact, I don't remember writing it, so somebody else must have written it... clever script :) Harold
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
Igor, So, can I get an example of how to do this setting of the PATH? Is it as easy as: PATH=/bin ??? Is it going to be a problem to have #!/bin/bash or #!/bin/sh at the top of the script? If so, what should that be instead? Harold
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
Igor, Igor Pechtchanski wrote: On Tue, 24 Feb 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: XFree86-f*.sh: umount, cygpath, mount Note: the above script should also check that the directory is already mounted in the correct mode instead of unmounting and remounting it all the time. The reason we force an unmount is that the mount point may, in fact, by pointing to a non-existant path. Touché. Make that ...already mounted off the correct path and in the correct mode I'm not sure if it would be easy to test that the path pointed to by a mount is valid and writable? Do you know of a clean way to do it? That means that setup.exe will extract our package files to /dev/null on an attempt at a first install with an invalid font mount point. However, most users will then attempt a second install; without the forced unmount/remount, the same problem would recur. The forced unmount/remount causes the second and subsequent installation attempts to succeed. OTOH, it's probably not that expensive to do anyway, so it might as well stay that way (especially since I was the one who originally suggested it) ;-) Yeah, it was a good idea :) I would love to solve this problem properly but pre-install scripts would be a real challenge for setup.exe, unless there was a concise set of rules about what packages could and could not have pre-install scripts, lest we end up with chicken before egg problems for some packages. Yes. Setup does support preremove scripts, though, and they could do the umount... It might be cheaper to do it the way it's done now, but if done in the preremove, at least the installation should succeed. Preremove scripts are from the previous installation of a package, correct? In other words, if you have foo-1.0 installed and you try to install foo-1.1, the preremove will be from foo-1.0, not from foo-1.1, right? If that is the case, then this won't help like a preinstall script would. See, most people that have reported this problem just delete the cygwin tree on their drive, which prevents any preremove scripts from being run, so that script would never run to fix the fonts mount point before the next unpacking of the fonts tarballs. Maybe the proper fix is to have setup.exe check if it is about to untar something into the ether. It is just amazing that you can have a stale mount point that causes a package to not be extracted correctly, yet setup.exe doesn't report that the installation failed at all. On the other hand, this may be a difficult fix, since we can't cull mount points that the user has setup because they may be for a network drive and they are simply not on the correct network at the time. Maybe we could temporarily prune any mounts that are invalid at the time, without changing the user's mount settings in the registry. That way the package would be unpacked somewhere, and our postinstall script would come along later and fix the mount point for /usr/X11R6/lib/fonts. How does that sound? XFree86-lib.sh: mkdir, test?, tar, rm, ln XFree86-prog.sh: touch, ln XFree86-xserv.sh: ln fontconfig.sh: dirname, basename, diff, cp, mkdir Note: this one also uses bash syntax. Moreover, it requires things like diff and dirname/basename to run, but neither diffutils nor sh-utils are in the requires clause of fontconfig. freetype2.sh: mkdir, ln I agree that I should probably hand-craft the PATH for all of the above scripts (including the XFree86-f*.sh scripts). Yeah, you're right, actually prepending /bin to the path might be a better solution for large scripts. But what I don't understand is why it didn't work when done from setup... Could it be an environment export issue of some sort? xfig.sh: mkdir, tar, rm, ln Note: tar should be required. Ditto. Interesting not about tar not being a required package. I never realized that that script used tar. In fact, I don't remember writing it, so somebody else must have written it... clever script :) Harold Yep, that's the best (easiest) way to copy a directory structure with symbolic links, etc, intact. I'm updating the xfig setup.hint files right now. I am also fixing the longstanding issue of depending upon ghostscript instead of 'ghostscript-x11 ghostscript-base'. This has caused numerous compliants about being unable to export figures correctly from xfig. Harold
Re: Heads-up: postinstall scripts and PATH (Attn all package maintainers)
Robert Collins wrote: On Wed, 2004-02-25 at 07:39, Harold L Hunt II wrote: I'm updating the xfig setup.hint files right now. I am also fixing the longstanding issue of depending upon ghostscript instead of 'ghostscript-x11 ghostscript-base'. This has caused numerous compliants about being unable to export figures correctly from xfig. if ghostscript-x11 depends on ghostscript-base, and you don't explicity call stuff in ghostscript-base, then you should not list ghostscript-base. I recall being told long ago that I should do just the opposite of what you are suggesting. I suggest that it does make sense to put in an explicit dependency on some such packages, though perhaps not all such packages, because if a user already has ghostscript-x11 and ghostscript-base installed, then manually uninstalls ghostscript-base, then selects xfig, I believe that ghostscript-base will not be reselected. Rather than field bug reports, I would prefer to just prevent that from happening. On the other hand, if setup.exe always does a full recalculation of dependecy trees when selecting a new package, then this will never be a problem and I can indeed remove ghostscript-base from the dependency list. Of course, I am lazy, so I have not tested this case recently. Harold
