Re: std::arg() bug : not repetitive ?
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). > In http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/00818.html it is argued that: > Nvidia started requiring SSE in their binary drivers, but have since > backed out that requirement, so it is possible to make people realize > their code has unreasonable requirements. 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. In the place where I was working until only last November, we had a ton of old P2 boxes around the place, doing useful jobs, and they all had Cygwin on them. It would have crippled us if we suddenly had to upgrade them all one day. OTOH maybe we could hack up a software SSE emulation for those users... cheers, DaveK
Re: zip and unzip from Info-ZIP version update
paul.hermeneutic wrote: > Is there any timeframe for unzip 6.0? I started down this path > because unzip does not currently have multi-part support. I > downloaded WinRAR, but I would prefer an open source solution if you > know of any. cygwin-1.7 already has unzip 6.0. It's just cygwin-1.5 that doesn't. I may or may not release unzip-6.0 for cygwin-1.5, depending on whether I have time between now and when cygwin-1.7.1 is released. No promises. (Don't try to install unzip-6.0-10 on a cygwin-1.5 system. It won't work.) -- Chuck
Re: zip and unzip from Info-ZIP version update
Chuck: My sincerest apologies. Clearly I made a mistake. Cygwin does have the current version of zip. Is there any timeframe for unzip 6.0? I started down this path because unzip does not currently have multi-part support. I downloaded WinRAR, but I would prefer an open source solution if you know of any. Kindest regards, Paul Watson On Wed, Sep 2, 2009 at 14:53, Charles Wilson wrote: > paul.hermeneutic-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: >> It would seem that Cygwin is using a somewhat old version of Info-ZIP >> from which zip and unzip are created. The info-zip.org >> >> >> From the http://info-zip.org/ site, there is: >> >> """ >> All known vulnerabilities are fixed in Zip 2.32. >> """ >> >> However, it appears that Cygwin is using version 3.0. > > err... "3.0" is newer than "2.32". The older 2.32 version fixed all > known vulnerabilities. 3.0 added additional features, but still > maintains all of the older 2.32 version's fixes to known vulnerabilities. > >> What is the process to get this updated? Please advise. Thanks. > > 3.0 is the most recent version, and has been available for cygwin since > March. > > http://cygwin.com/ml/cygwin-announce/2009-03/msg00027.html > > -- > Chuck >
Re: Start menu shortcuts
Jon TURNEY wrote: > I'm not sure what to do about X-start-menu-icons. > > I think Yaakov has some ideas about how to approach this, but I don't > know what they are. > > Anyhow, this is something I am willing to spend a bit of time on, if > there was some vague consensus as to the direction we should be heading in. IMO, each (X) package should, in its own postinstall script, create the start menu shortcut it needs, using mkshortcut from cygutils. That postinstall script should also invoke whatever tool is necessary and supported to add its opendesktop menu items to the cygwin area, so that cygwin/gnome and/or cygwin/kde window managers are happy -- at the package maintainer's discretion. I believe Yaakov's ideas revolve around automating this with certain primitives to be invoked within .cygport packaging scripts. How to manange the transition, from the monolithic X-start-menu-icons package and script, to this distributed approach -- no idea. -- Chuck
Re: zip and unzip from Info-ZIP version update
paul.hermeneutic-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: > It would seem that Cygwin is using a somewhat old version of Info-ZIP > from which zip and unzip are created. The info-zip.org > > > From the http://info-zip.org/ site, there is: > > """ > All known vulnerabilities are fixed in Zip 2.32. > """ > > However, it appears that Cygwin is using version 3.0. err... "3.0" is newer than "2.32". The older 2.32 version fixed all known vulnerabilities. 3.0 added additional features, but still maintains all of the older 2.32 version's fixes to known vulnerabilities. > What is the process to get this updated? Please advise. Thanks. 3.0 is the most recent version, and has been available for cygwin since March. http://cygwin.com/ml/cygwin-announce/2009-03/msg00027.html -- Chuck
zip and unzip from Info-ZIP version update
It would seem that Cygwin is using a somewhat old version of Info-ZIP from which zip and unzip are created. The info-zip.org >From the http://info-zip.org/ site, there is: """ All known vulnerabilities are fixed in Zip 2.32. """ However, it appears that Cygwin is using version 3.0. What is the process to get this updated? Please advise. Thanks.
Re: Start menu shortcuts
On 19/08/2009 01:05, Ken Brown wrote: On 8/18/2009 10:46 AM, Ken Brown wrote: Is there a policy about which packages are allowed to create start menu shortcuts? Recent discussion about run.exe on the main cygwin list makes me think it would be useful for the emacs-X11 package to create a shortcut for starting emacs under X. I would do this by putting the following in the postinstall script: /usr/bin/mkdir -p "$(/usr/bin/cygpath -AP)/Cygwin-X" /usr/bin/mkshortcut -AP \ -n Cygwin-X/emacs \ -w /usr/bin \ -i /usr/share/emacs/23.1/etc/emacs.ico \ -a '-p /usr/bin bash -l -c "emacs --display=127.0.0.1:0"' \ /usr/bin/run.exe Is this appropriate or does it violate some guidelines? I just realized that the X-start-menu-icons package already provides an emacs shortcut, so my question is irrelevant. But emacs started by the shortcut in that package doesn't work right because the PATH isn't set up correctly. (For example, if you try to list the current directory with C-x d, you get an error "ls not found".) So it should either be fixed as above or removed from X-start-menu-icons, in which case I'll add it to emacs-X11. I'm not sure what to do about X-start-menu-icons. On the one hand, it is a bit silly now that we have individual packages for each executable rather than everything in xorg-x11-bin, and perhaps it would make much more sense for the individual packages to maintain their own start menu shortcuts. On the other hand, it makes sense for those applications which want to have a start menu icon to be using some kind of standard tool to maintain that start menu shortcut, and X-start-menu-icons.sh is probably that tool :-) On the gripping hand, as it stands, it's a bit broken: - X-start-menu-icons.sh only gets automatically run by the X-start-menu-icons package's postinstall script. It really needs to get run after every setup run to check if it needs to create shortcuts for any newly installed applications. - It only knows how to add shortcuts for applications, and to remove all the shortcuts it's made (on it's own uninstallation). It doesn't know how to delete the shortcuts for applications which are owned by uninstalled packages, leading to stale shortcuts for removed applications. - it can't make shortcuts with external icons, like the example above - as you point out, it doesn't make a correctly working shortcuts for emacs (everything should probably be invoked via bash -l -c so a useful environment exists) - /etc/X11/X-start-menu-icons-list contains the hardcoded list of applications which get start menu shortcuts. This data clearly ought to be in individual packages. (So this perhaps this should be replaced by a directory with files owned by the individual packages?) - if you have parallel 1.5 and 1.7 installations, they will fight over the shortcuts, as they want to create shortcuts with the same name, but have differing ideas of where they should point to... I think Yaakov has some ideas about how to approach this, but I don't know what they are. Anyhow, this is something I am willing to spend a bit of time on, if there was some vague consensus as to the direction we should be heading in.
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: std::arg() bug : not repetitive ?
--- Mer 2/9/09, Dave Korn ha scritto: > Da: Dave Korn > Oggetto: Re: std::arg() bug : not repetitive ? > A: "Marco Atzeri" > Cc: cygwin cygwin.com, "Dave Korn" > Data: Mercoledì 2 settembre 2009, 12:43 > Marco Atzeri wrote: > > > Are this setting acceptable for a cygwin package ? > > > > -march=pentium4 -msse -mfpmath=sse > > I think this bit of the thread should move to the > -apps list. I can't > answer your question directly, but I'll note that CPUs > without SSE support > must be pretty thinly spread these days. But, if we > do this, it really is the > complete death of backward-compatibility for those older > CPUs. I can't say > how much of a bad thing that would be. > > cheers, > DaveK > I also don't like such solution. I also noted that only -msse -mfpmath=sse is not effective, and I have no clue if -march=pentium4 is acceptable for AMD cpu's. Cheers Marco
