Re: Avoiding the final setup.exe page
On Sun, 20 Sep 2009, Christopher Faylor wrote: > People have complained about the final setup.exe page which asks about > creating an icon, etc. What's the best way to stop that page from > showing up every time you run setup.exe? Should it only be asked on the > very first installation (easy) or should there be a "Don't ask this > question again" (harder)? > > And, if that page goes away, should setup.exe just exit when it is > done or should it still have something that you click? FWIW, I think the current behavior of remembering past choices and giving the option to change them, while at the same time showing a positive notification of success full completion, is just fine the way it is. AFAIK, the success full completion page is industry standard for Windows installers. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew...
Re: std::arg() bug : not repetitive ?
On Thu, 3 Sep 2009, Dave Korn wrote: > Brian Ford wrote: > > On Wed, 2 Sep 2009, Marco Atzeri wrote: > > > >> I have no clue if -march=pentium4 is acceptable for AMD cpu's. > > > > FWIW, we have been using -march=pentium4 -mfpmath=sse successfully in a > > very large software project since November 2003 without incident. We have > > run on AMD Opterons and a variety of Intel processors without issue > > (given that they were at least Pentium 4's, of course). > > If we turn on SSE in the distro, we block anyone using Pentium2 or early > (pre-XP) Athlon CPUs from using Cygwin. I think that might be a step too far. Just to be clear, I'm neutral with respect to this decision, and I wasn't suggesting it should be done. I only wanted to state that this combination of optimization flags is stable, works on the proper subset of AMD as well as Intel processors, and provides a real world performance benefit when the processor compatibility compromise is deemed acceptable. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew...
Re: std::arg() bug : not repetitive ?
On Wed, 2 Sep 2009, Marco Atzeri wrote: > I have no clue if -march=pentium4 is acceptable for AMD cpu's. FWIW, we have been using -march=pentium4 -mfpmath=sse successfully in a very large software project since November 2003 without incident. We have run on AMD Opterons and a variety of Intel processors without issue (given that they were at least Pentium 4's, of course). -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew...
Re: [ITA] lesstif
On Tue, 4 Nov 2008, Yaakov (Cygwin Ports) wrote: > Brian, > > As part of the X11 transition, I would like your permission to take over > the lesstif package. It is a dependency of libGLw from Mesa, which will > be part of the modular X11 upgrade, as well as a number of other X11 > packages whose dependencies will need to be updated. > > I would immediately update lesstif to 0.95.0 with the /usr prefix, and > remove the dependency on the obsolete libXp6. > > I appreciate your consideration, Sure, go ahead. I don't seem to have much time or value added for this anymore anyway. Thanks. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew...
Re: ImageMagick problems
On Sat, 19 Aug 2006, Harold L Hunt II wrote: > * lesstif (Brian Ford has this now, right?) Yes, this is mine, and I'm hopelessly overdue getting the release out of test state. Hopefully it will come sometime soon now. Then again, I don't see anyone complaining ;-). -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... .
Re: Consensus about man and doc X11 directory structure
On Mon, 10 Oct 2005, Dr. Volker Zell wrote: > I propose that documentation in general should go to /usr/share/doc/$PACKAGE > even for X11 packages and the main man page directory should be dictated > by the generic X11 tree, which is right now /usr/X11R6/man/manX (X=1,) > > Any comments ? Why do you propose keeping a distinct X11R6 tree yet puting documentation outside it. I would prefer these to be consistent. IIRC, Harold had decided to eliminate the X11R6 subtree and cgf agreed. I guess that was the direction Xorg and several Linux distros were taking. http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00228.html IMHO, that was not desirable. Eventually I could imagine X11 and Cygwin native versions of the same package. I liked this method of making the distinction. > The situation right now is: [snip] > Docs pages not belonging to the x11-org packages: > = > > /usr/X11R6/doc: > > fvwm-2.4.7 > lesstif-0.93.94 > libPropList-0.10.1 > openbox-0.99.1 > transfig-3.2.4 <- empty > x2x-1.30 > Xaw3d-1.5D > xfig-3.2.4 > xgraph-12.1 > xpdf-0.91 I believe these are simply packages that have not been updated since the FHS standards began being enforced. > /usr/X11R6/share/doc: > > xorg-x11-xwin > freeglut-2.2.0 > gv-3.5.8 > libXft-2.1.6 > nedit-5.5 > tcm-2.20 > WindowMaker-0.90.0 > X-start-menu-icons-1.0.3 > X-startup-scripts-1.0.10 > x3270-3.2.20 > XmHTML-1.1.7 > xwinclip-1.2.0 These would appear correct from my point of view. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: lesstif packaging
On Wed, 28 Sep 2005, Nicholas Wourms wrote: > On 9/27/05, Brian Ford wrote: > > On Mon, 26 Sep 2005, Nicholas Wourms wrote: > > > Please go back to bzipping the manpages like they have been in previous > > > packages. > > > > I see now that this was the case. > > > > However, the source package that Harold gave me to start with did not do > > this, nor does the current version of the gbs. As such, I'd prefer not to > > support a local gbs patch just to change its default behavior. If, > > however, there is consensus that this is "the way it should be" (TM), I'd > > be happy to submit a gbs patch. > > I don't know anyone who uses the gbs without tweaking it for a > specific package, which you've already done for lesstif. That's not the point. This tweak would be changing a globally accepted default. As far as I'm concerned, either we all want to gzip the man pages, or we all want to bzip2 them. It makes no sense to me what so ever for this to be an individual package's choice. And, it would appear from his response that cgf prefers to stick with gzip. > > > Also, please don't just arbitrarily drop the static libs. > > > > Why? None of the dependent xorg X libs are available staticly. How does > > having a static lesstif help anyone? If you can present a reasonable > > argument for keeping them I will consider it, but no for an unfounded > > request. Sorry. > > First, I do not know if it is still the case, but in the past, *some* > motif applications had problems when linked to the dynamic library. Most, but only with the initial attempt to make it a dll. > In fact this issue caused a lot of headaches when lesstif was first > introduced, but eventually it was fixed for most applications. All. If you have a specific example to the contrary, please report it and I'll take a look. > A search of the archive ought to show the relevant discussion. No need. I was heavily involved in that discussion because at the time I was serving as proxy lesstif maintainer for Harold. > While I agree that the lack of static Xorg libs is less than desirable, I, on the other hand, believe it is perfectly desirable. > it is has been a general courtesy to provide both static and dynamic > libs to the developer. One reason might be that an app uses only a few > portions of lesstif libs, but the dev doesn't want to require the user > to install the entire lesstif package. It would be next to impossible to use only a portion of the lesstif libs, especially without using any xorg dlls. You are making a general argument that does not apply here again. Please make a specific one or drop it. > In any event, I'll withdraw that particular request until such time as > static Xorg libs become available. Oh..., ok..., good. I'm pretty sure the never will be. > I'm not sure what the status is, but I contacted Alexander awhile back > regarding Xorg static libs and IIRC he told me he was going to look > into it when he gets a chance. You realize that Alexander is no longer maintaining Cygwin X, right? > If he's too busy still, I've been playing around with Xorg's build and > can probably get it working sooner or later. That's between you and the new (very busy and currently absent) xorg maintainer. If he produces them, or if someone presents a non-generalized argument, I'll reconsider. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: lesstif packaging
On Mon, 26 Sep 2005, Nicholas Wourms wrote: Nicholas, You have been around here long enough to know that personal email is not the way to address these issues. As such, I have forwarded this reply to the proper mailing list and set the Reply To appropriately. Please honor this. The lack of doing so makes it less likely that your request will be addressed. Thanks. > Please go back to bzipping the manpages like they have been in previous > packages. I see now that this was the case. However, the source package that Harold gave me to start with did not do this, nor does the current version of the gbs. As such, I'd prefer not to support a local gbs patch just to change its default behavior. If, however, there is consensus that this is "the way it should be" (TM), I'd be happy to submit a gbs patch. > Also, please don't just arbitrarily drop the static libs. Why? None of the dependent xorg X libs are available staticly. How does having a static lesstif help anyone? If you can present a reasonable argument for keeping them I will consider it, but no for an unfounded request. Sorry. Is there any general consensus on either of these two points? ie: 1.) bziping vs gziping man pages. 2.) When to package static libs too. Google didn't turn up much quickly. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: please upload: lesstif-0.94.4-1 test release
On Wed, 21 Sep 2005, Christopher Faylor wrote: > I wasn't following the back and forth about this. Why are there > explicit dependencies in setup.hint which skip over lesstif-0.93.96-2? > >On Wed, 21 Sep 2005, Brian Ford wrote: > > > >> As far as I'm concerned, the previous test release, 0.93.96-2, may be > >> removed. > If this version isn't going to be used, then we might as well just > delete it and use the natural version sorting. It was my understanding that when a test release is present, all versions need to be explicitly stated in setup.hint. If this is incorrect, the following paragraphs from http://cygwin.com/setup.html need to be corrected: In general, you should trust the automatic setup.ini generator to "do the right thing" -- with one exception. If you decide that you need to release a test version of your package, there is no way for the setup.ini generator to know that. So, you will have to put something like "test: 1.9-1" in your setup.hint file. This will cause setup.exe to characterize the 1.9-1 version as a "test" package. With the current setup.exe implementation, it will also mean that it will be overlooked by most people during installation. So, unless you have made arrangements to advertise your test release, this option should be used sparingly. Note that if any of the curr, prev, or test options are used, they will short circuit all of the automatic version detection used for generating setup.ini. So, if you include a test option, and you have valid current and/or previous tar files, you must specify curr and/or prev. Otherwise, the only version that setup.exe will display will be the test version. > prev: 0.93.91-6 > curr: 0.93.94-2 > test: 0.94.4-1 Signed, The confused candidate Cygwin LessTif maintainer... -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: please upload: lesstif-0.94.4-1 test release
To remove indirect dependencies from setup.hint, and to update the Cygwin specific README file accordingly, these files have been updated. I assume this was done quick enough to avoid the need to bump the release number. On Wed, 21 Sep 2005, Brian Ford wrote: > Here are the files: > > http://members.socket.net/~amyka/lesstif-0.94.4-1.tar.bz2 > http://members.socket.net/~amyka/lesstif-0.94.4-1-src.tar.bz2 > http://members.socket.net/~amyka/setup.hint > > As far as I'm concerned, the previous test release, 0.93.96-2, may be > removed. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
please upload: lesstif-0.94.4-1 test release
I believe Harold gave me permission to upload a test release of LessTif in an effort to transition its maintainership. This is a test release because various Cygwin maintainers whose packages rely on LessTif may have compatibility concerns. Those packages are: ddd nedit tcm xemacs xpdf If you are a maintainer or user of one of the above packages, please test this release. Also, if you are a developer who uses Cygwin LessTif, your input is also desired. Note that you can test the new cygXm-2.dll without needing to recompile the dependent application. Although, a recompile is a more thorough test, assuming you are sure the recompile would have succeeded before this update. Since this is a maintainership change, a packaging review may be in order? Here are the files: http://members.socket.net/~amyka/lesstif-0.94.4-1.tar.bz2 http://members.socket.net/~amyka/lesstif-0.94.4-1-src.tar.bz2 http://members.socket.net/~amyka/setup.hint As far as I'm concerned, the previous test release, 0.93.96-2, may be removed. Changes: * Sync with upstream release (see http://www.lesstif.org/ReleaseNotes.html for details) * Disable static libraries. * Sync with latest gbs. * acinclude.m4 (AC_FIND_XFT): Make compatible with libfreetype26-devel-2.1.9-1. * Update lesstif.README. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: lesstif
On Fri, 16 Sep 2005, Harold L Hunt II wrote: > Hold up... am I not reading something correctly? Was the binutils > change that caused the problem ever reverted? IIRC, it was a gcc change that caused the problem. Although, there may have been a binutils work around. > If not, the problem will still exist. It may, but... > I never heard that the change was reverted, I don't think it was, but... > so I'm wondering why binutils being up to date matters at all. See speculation about binutils work around above. Did you try updating? But... > IIRC, with the binutils change in place, gcc change > the only way to address the issue would be to change nedit to no longer > do relocs in now-non-writable data, which would probably take a week. Here may be where the misunderstanding lies. That statement may be true, but it doesn't matter because it would only come into play if/when nedit was updated (ie. recompiled with gcc >= 3.3.1). This is not necessary because of, or to use the new lesstif. This is what I tested, but may not be what you tested. Hence our differing results. > 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) Unfortunately, as I stated before, you never reported this to me, so I am unable to reproduce or debug it. > Look, the history doesn't matter. I'm not really trying to reproduce history, just to clarify enough to move forward since our recollections seem to differ greatly. > The point here is that I won't let someone release a version of lesstif > that breaks nedit... Fine, please define how to break nedit and I'll make sure it doesn't happen. Until we have a confirmed bug that is reproducible, you can't expect me to go beyond a simple does nedit work to open, edit, and save files type of test can you? > now, if you're sure that nedit works just fine with your new lesstif > build, No one really can be, but it basically does... > 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 I don't understand what this means. Could you clarify what "no other modifications from me" means? I have made no modifications to the released nedit or to your lesstif-0.94.4 source package. They just work (TM). > 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. Until I know what you mean by the above, I can't say I have done it. But, IWJFFM. > If it works, fine, proceed... I had planned to. I have maybe just found web space to post packages, but there is a fairly small 5M-10M limit. We'll see if lesstif fits... If anyone knows of a free site suitable for such, please let me know (via private email if you so desire). I don't remember anyone posting one that didn't have significant issues with package names, space, etc. > 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. As soon as someone can identify a problem with nedit... > Deal? Agreed. I'll be glad to leave my new version in test for a month or so to see if anything turns up. But, given the standard Cygwin philosophy for testing, I expect nothing will until it goes curr ;-). -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
RE: lesstif
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? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: lesstif
On Thu, 15 Sep 2005, Harold L Hunt II wrote: > Brian Ford wrote: > > 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. Sorry, I never received any more communication from you after the message I quoted. Although, I did ping you once about a month later. Again, there was no response. I was about to ping again when I saw this message. > 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, I don't have access to VMWare, or the time to build a Windows system with Cygwin from scratch for this. That really seems silly to me. Isn't a comparison of cygcheck output all that should be necessary to determine any differences? Alternatively, we could get an impartial third party opinion (ie. have someone else do a source build of lesstif-0.94.4, and check it with nedit)? > compile the two packages and see what happens. I only compiled the one (lesstif) and had the old nedit use the resulting cygXm-2.dll (confirmed by cygcheck output). That is all that's required. > 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). If you want me to play around, you'll need to be more specific. It opened a file fine, and that's where I stopped. I have now opened a few files, done some edits, a few cut and pastes, a save, etc... I don't use nedit, thus I can't stress it much. 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 Brian, 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. --- OK --- > > 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. I'll see about getting it packaged up soon. My biggest hurdle will be the one of finding an upload space. > Harold "No need to CC me in replies" Hunt I'm truly sorry about that. I have gotten used to doing a reply all for my normal mail here at work and did it out of habit. I do honor Reply To, though. I noticed it, but thought you had asked for it with Reply To. My bad :-(. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: lesstif
On Thu, 15 Sep 2005, Harold L Hunt II wrote: > Brian Ford wrote: > > On Thu, 15 Sep 2005, Harold L Hunt II wrote: > >>lesstif (won't do new versions) > > > > Since I've been trying to get you to release a new one of these for a > > while now, does this mean I can have it? > > Sure, but, if you take lesstif you have to also take responsibility for > nedit, which doesn't mean that you have to maintain it, but you have to > recognize that a lesstif release that works for an in-house app but > makes nedit crash upon opening a document is unacceptable. Agreed, but... > 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. Do you want to look into this, or do you just want to give lesstif to me? Date: Thu, 7 Jul 2005 23:16:13 -0500 From: Brian Ford To: Harold L Hunt Subject: Re: lesstif update request [files this time] Sorry for the late reply. I've been totally swamped the last two days. On Tue, 5 Jul 2005, Brian Ford wrote: > On Tue, 5 Jul 2005, Harold L Hunt wrote: > > What are your thoughts? > > I'll try your patchset and see if I can find the offending const > decorators soon. Thanks again. Well, I tried your patchset, without any other modifications, and the resulting cygXm-2.dll appears to work perfectly. It even fixed the scroll list callback bug on up arrow that prompted me to request the update. And, the mouse wheel now scrolls too :-). So, the only thing I can guess, is that your compiler or binutls is out of date. Here are my versions: gcc 3.4.4-1 gcc-ada 3.4.4-1 gcc-core3.4.4-1 gcc-g++ 3.4.4-1 gcc-g77 3.4.4-1 gcc-gdc 3.4.4-1 gcc-gpc 3.3.3-3 gcc-java3.4.4-1 gcc-mingw 20040810-1 gcc-mingw-ada 20050522-1 gcc-mingw-core 20050522-1 gcc-mingw-g++ 20050522-1 gcc-mingw-g77 20050522-1 gcc-mingw-gdc 20050522-1 gcc-mingw-gpc 20040810-1 gcc-mingw-java 20050522-1 gcc-mingw-objc 20050522-1 gcc-objc3.4.4-1 binutils20050608-2 cygwin 1.5.17-1 This isn't related, but you might also consider the attached patch to properly decorate the exported/imported lesstif symbols. It should fix the abundance of auto-import info messages when compiling lesstif applications. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, 15 Sep 2005, Harold L Hunt II wrote: > lesstif (won't do new versions) Since I've been trying to get you to release a new one of these for a while now, does this mean I can have it? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Igor Pechtchanski wrote: > On Tue, 5 Jul 2005, Eric Blake wrote: > > OK, then, does anyone else have ideas on how to determine if /bin/sh > > is ash with resorting to running it, and without resorting to packing > > an ever-increasing list of known md5sums of all prior versions in the > > bash postinstall script? > > I do. :-) Run "cmp /bin/bash /bin/sh" in the preremove script, when > you're guaranteed that if /bin/sh is bash, it's the exact same bash that > is currently installed. I second that method. It's the only thing that makes sense to me. > Why all this effort of avoiding removing /bin/sh? The two times the > preremove script would be run are on uninstall and on upgrade. Uninstall > should be disallowed by other means (e.g., explicitly checking in setup > when packages in Base are uninstalled), and upgrades are harmless, IMO. > So why try to avoid removing /bin/sh in a preremove script? FWIW, I agree with this too. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: Bug tracking services?
I hate to cross post like this, but I think it's appropriate for the question posed... On Wed, 27 Oct 2004, Christopher Faylor wrote: > I've set up the categories for cygwin: > > http://sourceware.org/bugzilla/describecomponents.cgi?product=cygwin Should the "Default Owner" be changed for Cygwin/X and setup.exe to Alex and Max respectively? Just curious... -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: setup: Bug tracking services?
On Wed, 27 Oct 2004, Max Bowsher wrote: > I find myself wishing for a bug tracker for setup. > > Is there any likelyhood of sources.redhat.com provided bug-trackers in the > future? > > For now, I'm contemplating throwing a quick install of Bugzilla (or other > software - suggestions very welcome in *private* mail) onto the student > webserver at my college Did you see: http://cygwin.com/ml/cygwin/2004-10/msg00194.html ? Reini and I offered to co-maintain it if CGF decides to follow through. Sounds like you have another point in favor? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: gcc 3.3.3 builds "corrupt" lesstif-0.93.94
On Fri, 22 Oct 2004, Christopher Faylor wrote: > On Fri, Oct 22, 2004 at 09:58:32AM -0500, Brian Ford wrote: > >You might also want to be aware of: > > > >http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html > > Does this mean that I should generate a new version of binutils? Not necessarily, it just means that I can't cut and paste between Windows Mozilla and Cygwin Pine in an rxvt terminal :-(. I meant to say: http://www.cygwin.com/ml/cygwin/2004-09/msg01263.html You must be reading my mind, though. For gcc 3.4, I'd say definately yes please. For gcc 3.3.3-3, it's still up in the air. I've yet to see a confirmed issue there. We are using custom built tools (gdb & gcc) to support DWARF 2, so adding a custom binutils as a work around for this issue was trivial. Thanks for asking. Maybe Harold will find a solid example of a problem between gcc-3.3.3 and binutils :shrug:. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: gcc 3.3.3 builds "corrupt" lesstif-0.93.94
On Thu, 21 Oct 2004, Harold L Hunt II wrote: > 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)? Sounds like: http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html no? You might also want to be aware of: http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html HTH -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: ITP: mingw-bzip2, mingw-libbz2_1 (FYI)
On Sun, 10 Oct 2004, Christopher Faylor wrote: > Funny, but I thought that we'd discussed this a while ago for use with > cygcheck but now I can't see why cygcheck would need it. http://www.cygwin.com/ml/cygwin/2003-09/msg00381.html ? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: pre-ITP: New category Gis?
On Sat, 9 Oct 2004, Reini Urban wrote: > libgeotiff is explicitly not needed, but maybe we want to have it extra > also. We'd like it separate. We are currently "maintaining" a local package. I may be interested in maintaining it publicly if no one else is. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
RE: Fixes to allow command line options to properly work
On Mon, 11 Oct 2004, Amir Ebrahimi wrote: > Igor, sorry about submitting the whole ChangeLog. This is the first time > I've contributed to a project ;) Should I have included my ChangeLog diff > in my patch file? No, just your entry as plain text. See: http://cygwin.com/contrib.html (When you have finalized your changes) for more details like: "ChangeLogs should *not* be sent as "diffs". Just send the complete ChangeLog entry." -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: forwarding of announcements disabled?
On Thu, 2 Sep 2004, Brian Ford wrote:
> Should I simply add a -c to the formail subject extraction? Other ideas?
This is just a follow up to close this issue. It looks like:
http://www.cygwin.com/cgi-bin/get-raw-msg?listname=cygwin-announce&date=2004-10&msgid=87brfhnsfq.fsf%40vzell-de.de.oracle.com
http://www.cygwin.com/cgi-bin/get-raw-msg?listname=cygwin&date=2004-10&msgid=200410051441.i95EfHa23419%40esds.vss.fsi.com
amoung others probably, confirms the fix described above worked. It does
appear to add an extra space in the subject where the newline was, though
(Library for generating...). If anyone knows how to fix that, please let
me know. Thanks.
Old context follows:
> On Mon, 23 Aug 2004, Brian Ford wrote:
> > On Mon, 23 Aug 2004, Andreas Seidl wrote:
> > > It seems mails are no longer forwarded (and prefixed with
> > > "[ANNOUNCEMENT]") from the cygwin-announce list to the cygwin list
> > > anymore. So I have to send mails to both lists?
> >
> > I looks like something in your message confused the procmail recipe and
> > it sent it back to cygwin-announce again. I'll look into it as soon as I
> > have time, but I'm swamped right now.
> >
> > This is working for the majority of announce messages, and the recipe is
> > exactly CGF's old one.
>
> CGF notified me that fowarding another of your announcements failed in
> the same manner. I took a closer look and found his procmail recipe is
> failing for subjects that contain embedded newlines. This has happened
> four times since I took over the forwarding; three of which were yours
> :-(.
[snip references]
> I'm afraid I need some help because I can't see how to fix this. I'm far
> from a procmail guru.
>
> Here is the recipe snippet:
>
> :0
> * ^TO_cygwin-announce
> {
> SUBJECT=`formail -xSubject:`
> FROM0=`formail -X'From '`
> FROM1=`formail -X'From:'`
>
> :0fW
> | formail -I '' \
> -I"$FROM0" \
> -I"$FROM1" \
> -I'To: cygwin-AT-cygwin-DOT-com' \
> -I"Subject: [ANNOUNCEMENT]$SUBJECT" \
> -I'Reply-To: cygwin-AT-cygwin-DOT-com'
>
> :0
> !cygwin-AT-cygwin-DOT-com
> }
>
> and the applicable verbose procmail log snippet:
>
> procmail: Executing "formail,-xSubject:"
> procmail: Assigning "SUBJECT= Updated: TeXmacs-1.0.4-4: A scientific wysiwyg Editor
> and Interface
> for Computer Algebra Systems"
> procmail: Executing "formail,-XFrom "
> procmail: Assigning "FROM0=From
> cygwin-announce-return-1243-ford=vss-DOT-fsi-DOT-com-AT-cygwin-DOT-com Thu Sep 2
> 12:59:48 2004" procmail: Executing "formail,-XFrom:"
> procmail: Assigning "FROM1=From: Andreas Seidl "
> procmail: Executing " formail -I '' \
> -I"$FROM0" \
> -I"$FROM1" \
> -I'To: cygwin-AT-cygwin-DOT-com' \
> -I"Subject: [ANNOUNCEMENT]$SUBJECT" \
> -I'Reply-To: cygwin-AT-cygwin-DOT-com'"
> Unmatched ".
> procmail: Error while writing to " formail -I '' \
> -I"$FROM0" \
> -I"$FROM1" \
> -I'To: cygwin-AT-cygwin-DOT-com' \
> -I"Subject: [ANNOUNCEMENT]$SUBJECT" \
> -I'Reply-To: cygwin-AT-cygwin-DOT-com'"
> procmail: Rescue of unfiltered data succeeded
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...
Re: forwarding of announcements disabled?
On Mon, 23 Aug 2004, Brian Ford wrote:
> On Mon, 23 Aug 2004, Andreas Seidl wrote:
>
> > It seems mails are no longer forwarded (and prefixed with
> > "[ANNOUNCEMENT]") from the cygwin-announce list to the cygwin list
> > anymore. So I have to send mails to both lists?
>
> I looks like something in your message confused the procmail recipe and
> it sent it back to cygwin-announce again. I'll look into it as soon as I
> have time, but I'm swamped right now.
>
> This is working for the majority of announce messages, and the recipe is
> exactly CGF's old one.
>
> Sorry...
CGF notified me that fowarding another of your announcements failed in
the same manner. I took a closer look and found his procmail recipe is
failing for subjects that contain embedded newlines. This has happened
four times since I took over the forwarding; three of which were yours
:-(.
http://www.cygwin.com/ml/cygwin-announce/2004-07/msg6.html
http://www.cygwin.com/ml/cygwin-announce/2004-08/msg00027.html
http://www.cygwin.com/ml/cygwin-announce/2004-08/msg00036.html
http://www.cygwin.com/ml/cygwin-announce/2004-08/msg00027.html
I'm afraid I need some help because I can't see how to fix this. I'm far
from a procmail guru.
Here is the recipe snippet:
:0
* ^TO_cygwin-announce
{
SUBJECT=`formail -xSubject:`
FROM0=`formail -X'From '`
FROM1=`formail -X'From:'`
:0fW
| formail -I '' \
-I"$FROM0" \
-I"$FROM1" \
-I'To: cygwin-AT-cygwin-DOT-com' \
-I"Subject: [ANNOUNCEMENT]$SUBJECT" \
-I'Reply-To: cygwin-AT-cygwin-DOT-com'
:0
!cygwin-AT-cygwin-DOT-com
}
and the applicable verbose procmail log snippet:
procmail: Executing "formail,-xSubject:"
procmail: Assigning "SUBJECT= Updated: TeXmacs-1.0.4-4: A scientific wysiwyg Editor
and Interface
for Computer Algebra Systems"
procmail: Executing "formail,-XFrom "
procmail: Assigning "FROM0=From
cygwin-announce-return-1243-ford=vss-DOT-fsi-DOT-com-AT-cygwin-DOT-com Thu Sep 2
12:59:48 2004" procmail: Executing "formail,-XFrom:"
procmail: Assigning "FROM1=From: Andreas Seidl "
procmail: Executing " formail -I '' \
-I"$FROM0" \
-I"$FROM1" \
-I'To: cygwin-AT-cygwin-DOT-com' \
-I"Subject: [ANNOUNCEMENT]$SUBJECT" \
-I'Reply-To: cygwin-AT-cygwin-DOT-com'"
Unmatched ".
procmail: Error while writing to " formail -I '' \
-I"$FROM0" \
-I"$FROM1" \
-I'To: cygwin-AT-cygwin-DOT-com' \
-I"Subject: [ANNOUNCEMENT]$SUBJECT" \
-I'Reply-To: cygwin-AT-cygwin-DOT-com'"
procmail: Rescue of unfiltered data succeeded
Should I simply add a -c to the formail subject extraction? Other ideas?
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...
Re: forwarding of announcements disabled?
On Mon, 23 Aug 2004, Andreas Seidl wrote: > It seems mails are no longer forwarded (and prefixed with > "[ANNOUNCEMENT]") from the cygwin-announce list to the cygwin list > anymore. So I have to send mails to both lists? I looks like something in your message confused the procmail recipe and it sent it back to cygwin-announce again. I'll look into it as soon as I have time, but I'm swamped right now. This is working for the majority of announce messages, and the recipe is exactly CGF's old one. Sorry... -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: postgresql date time at Cygwin On Windows 2000 - workaround available?
Wrong list. Please re-read: http://cygwin.com/lists.html redirecting... On Wed, 28 Apr 2004, Mike Preston wrote: > Referencing > http://archives.postgresql.org/pgsql-cygwin/2004-03/msg1.php, is > there any workaround to reset the Postgresql 'system' time as it reads > it from Cygwin? We have some time-sensitive data, and the Postgresql > time is four days and four hours (plus) off the system time. We don't > mind having to manually reset periodically, but can't find a way to do > this. Suggestions? Don't know. http://cygwin.com/acronyms/#PTC for Cygwin, at least. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
ddd-3.3.8-1 packaging error
This is just a note to Harold so he can correct this error for his next ddd release (whenever that is). Ddd is an X11 app, so it should be rooted in /usr/X11R6 rather than /usr. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Re: List of package owners
On Sat, 20 Sep 2003, Igor Pechtchanski wrote: >On Sat, 20 Sep 2003, Christopher Faylor wrote: > >> lesstif Harold L Hunt II > >I believe the maintainer is actually Brian Ford (see ><http://cygwin.com/ml/cygwin-xfree/2003-09/msg00348.html>). > Well, kind of. I guess you could call me the proxy maintainer. Harold said he just released the initial package to get people started, and that he wasn't interested in maintaining it. I needed some bug fixes from newer versions, so we struck a deal. I provide updates to Harold on my time table and try to reasonably support those updates. He graciously accepts and publishes them. But, I haven't really committed for the long haul yet. So, I guess his name is as good as any. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Re: Corinna Vinschen
Oops! I swiped the wrong line for the subject. It should have obviously been "Re: Waiting for xfree86? [Was: guile-1.6.4-1]". Sorry! -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Corinna Vinschen
On Tue, Jul 22, 2003 at 20:45:23PM +0200, Corinna Vinschen wrote: >On Tue, Jul 22, 2003 at 12:25:51PM -0500, Brian Ford wrote: > >> I compile the program stuff.exe that depends upon the non-rebuilt dll >> foo.dll. No interfaces between stuff.exe and foo.dll were changed in >> 1.5.0, but foo.dll calls lseek. >> >> Now, when lseek in foo.dll is resolved at link time with the 1.5.0 >> cygwin1.dll, lseek resolves to lseek64. But foo.dll wanted plain old >> lseek. >> >> Do I have this right, or am I still seriously confused? > >Confused, I guess. You're mixing link time with load time. Link >time is when gcc (actually ld) creates the dll. Load time is when >the dll is loaded into memory on demand of an application linked >against symbols in that dll. > >The dependency on lseek has been resolved at link time, the time when >foo.dll has been created. Therefore, if foo.dll expects lseek, it gets >lseek on load time. > >When rebuilding foo.dll, the dependency to lseek is converted to a >dependency on lseek64 in the created dll already at link time. >`nm foo.dll' will show you the symbol lseek64. When foo.dll is loaded >into memory it expects to get lseek64 now. > That makes me feel a lot better. Just one last clarification. If stuff.exe also calls lseek, it will get lseek64 at link time, and foo.dll will still use lseek. So, they each operate seperately, but happily, be it in their respective 64 or 32 bit world? Thanks a lot for your patience. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Re: Waiting for xfree86? [Was: guile-1.6.4-1]
On Mon, Jul 21, 2003 at 15:54:29 -0400, Christopher Faylor wrote: >On Mon, Jul 21, 2003 at 08:17:44PM +0200, Jan Nieuwenhuizen wrote: > >>Christopher Faylor <[EMAIL PROTECTED]> writes: >> >>> Why are we waiting for these libraries? Do they export variables or >>> functions which rely on new 64 bit types? >> >>I haven't investigated that. It's just that they are listed in: >> >>http://www.mail-archive.com/[EMAIL PROTECTED]/msg07117.html > >I suspect that Chuck was a little overzealous in listing packages. As I >have been saying (and saying, and saying...) there is no need to rebuild >a package unless its interface has changed. > A clarification question again. Sorry. If a package is rebuilt, and it links with non-rebuilt libraries, will there be trouble even if the non-rebuilt libraries do not export interfaces that changed? Maybe my definition of "interfaces that changed" is wrong, or maybe I don't understand the method still, but here is an example. I compile the program stuff.exe that depends upon the non-rebuilt dll foo.dll. No interfaces between stuff.exe and foo.dll were changed in 1.5.0, but foo.dll calls lseek. Now, when lseek in foo.dll is resolved at link time with the 1.5.0 cygwin1.dll, lseek resolves to lseek64. But foo.dll wanted plain old lseek. Do I have this right, or am I still seriously confused? Thanks for your patience. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Re: HEADSUP package maintainers: Welcome to Cygwin 1.5.0
Sorry, I should have asked about this back on cygwin-developers, but I wasn't thinking that hard about it then. On Thu, 10 Jul 2003, Corinna Vinschen wrote: > lseek and lseek64 are both exported from the Cygwin DLL. Old > applications still use the lseek entry point since they don't know > better. Newly build applications on the other hand will use the > lseek64 entry point directly. But how do they know? That's done > at link time. The new libcygwin.a import library translates call > to lseek to calls to lseek64 transparently. Applications don't have > to know anything, they just get it for free. > Do you really mean at link time? If these were translated via the headers at compile time, then new executables with old libraries might have a better chance at working, each in their own 32 or 64 bit world, but together. Obviously, they still couldn't pass the types that changed sizes between them, though. > This means, the package maintainers of libraries, especially those > which provide DLLs should build a new version of their packages > as soon as possible. Only with all libs finished, we can finally > migrate the whole Cygwin net distro to 64 bit. > So, I'll ask again. What about libraries that depend on libraries? Wait, or go? Thanks for your help, and your hard work to make this happen is greatly appreciated. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
