http://blog.gmane.org/gmane.os.cygwin.applications hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.cygwin.applications/25915 <pre> Right. No. Every service needs a unique service name, otherwise you couldn't manipulate services unambiguously. Right now we have "Cygwin" and "Cygwin-X" folders in the start menu. Maybe we should just change the subdir names to "Cygwin 64" and "Cygwin-X 64", and otherwise stick to the shortcut names. I think only setup creates a desktop shortcut. Setup64 creates the "Cygwin64 Terminal", so if we keep it this way we're off the hook, I guess. Corinna </pre> Corinna Vinschen 2013-05-23T15:19:08 http://permalink.gmane.org/gmane.os.cygwin.applications/25914 <pre>I have to wonder: How do other packages with 32/64-bit binaries handle this? Maybe Cygwin is unique but there might be other packages out there which also have to deal with this. </pre> Christopher Faylor 2013-05-23T15:10:20 http://permalink.gmane.org/gmane.os.cygwin.applications/25913 <pre> Some of this is has got to be "the user has to know what they're doing". They obviously just *can't* install two different telnet or smtp servers, any more than they could have both a windows telnet server and a cygwin one. They would have to choose. For services, isn't there some other field besides just the name which can be used as a delineator? For shortcuts, I don't see anything wrong with adding a "Cygwin 64" to the name. </pre> Christopher Faylor 2013-05-23T15:01:05 http://permalink.gmane.org/gmane.os.cygwin.applications/25912 <pre> Yes, of course, because cygserver is bound to the installation path *and* there are no provisions in cygserver to handle processes of different architecture. Therefore my question... Corinna </pre> Corinna Vinschen 2013-05-23T09:35:24 http://permalink.gmane.org/gmane.os.cygwin.applications/25911 <pre>Il 5/23/2013 10:44 AM, Corinna Vinschen ha scritto: my experience with postgreSQL says that the two services are not interchangeable. 32 bit program fails with 64 cygserver Marco </pre> marco atzeri 2013-05-23T09:24:11 http://permalink.gmane.org/gmane.os.cygwin.applications/25910 <pre>Hi guys, Yaakov brought this up in a private IRC conversation a couple of weeks ago, but I dismissed it at the time. But I guess we have to discuss this. Consider somebody has 32 and 64 bit Cygwin installed in parallel. At least for developers and package maintainers this won't be that uncommon. Now, they will run in parallel just fine, and most of our packages don't do anything outside of the cygwin installation dir. However, there are a couple of packages which change the system on a global basis. I see three groups here: 1. Packages installing shortcuts in the start menu and/or desktop (this includes setup itself). #1 types could be solved rather easily if we attach a "64" to all the created shortcuts. But do we really want that, considering a setup for a "normal" user with only a single installation? What are the trade-offs? 2. Packages installing services. #2 packages have a service name collision. Obviously you can't install two services called "cron". Should the package install its service under another name, again by just attaching a "64" to the service name? This would require to change the service installer scripts to check on what platform they are running and then attaching the "64" suffix if `uname -m' returns "x86_64". An alternative would be to change cygrunsrv so that the 64 bit version always attaches the "64" automatically. While this is easy to accomplish, I see a problem here because the name change is not transparent to the user, nor to scripts. Having said that, the name change from "cron" to "cron64" is also kind of cumbersome. Usually you only need one service, either the 32 or the 64 bit version, but not both. So, do we want the name change at all? But what about cygserver? Without cygserver there's no XSI IPC. Even if we don't change the service names on a general basis, shouldn't cygserver at least be available in parallel, using different service names? 3. Packages installing network services. As for the #3 packages, they collide in another way as well since a service is usually connected with a default port. Sshd is expected on port 22. Telnet on port 23, smtp on port 25, etc. I don't think it would be the right thing to move all 64 bit server to other ports by default. I don't see any satisfactory way to install those services in parallel with a simple installer script, so I would keep this to the knowledgable user. And here it might be even helpful that the service names already collide since it disallows to install two network services Right? Wrong? Neither right nor wrong? Corinna </pre> Corinna Vinschen 2013-05-23T08:44:35 http://permalink.gmane.org/gmane.os.cygwin.applications/25909 <pre>Hi Chuck, is there a chance we can get a 64 bit "run" package any time soon? It's required for starting X from the start menu... Thanks, Corinna </pre> Corinna Vinschen 2013-05-23T08:22:38 http://permalink.gmane.org/gmane.os.cygwin.applications/25908 <pre> There's the misunderstanding. Whatever you actually wrote, I understood it so that this is the directory meant for any package upload, also manual ones. Good to know. Thanks, Corinna </pre> Corinna Vinschen 2013-05-23T08:03:11 http://permalink.gmane.org/gmane.os.cygwin.applications/25907 <pre> If I check my sent email folder, the only thing that I can see which suggests that this directory should be used for general use is email from you telling someone to use it. AFAICT, I created the directory and I did so for get-cygwin-package. My plan was to make this a place for automated uploads. If I told people to use this then I was really mistaken. Your home directory is a fine place for dealing with cygwin uploads, especially since the new sourceware places /home in the same partition as the ftp area. cgf </pre> Christopher Faylor 2013-05-22T18:35:33 http://permalink.gmane.org/gmane.os.cygwin.applications/25906 <pre>Il 5/22/2013 6:52 PM, Corinna Vinschen ha scritto: I had the same impression. I was using it for temporary storage during upload phase before moving to release areas (32 and 64 ) Marco </pre> marco atzeri 2013-05-22T17:14:08 http://permalink.gmane.org/gmane.os.cygwin.applications/25905 <pre> Uhm... am I the only one here who thought this is *the* general upload directory for Cygwin packages? Since that's apparently not right, what *is* the general upload directory for Cygwin packages? Corinna </pre> Corinna Vinschen 2013-05-22T16:52:28 http://permalink.gmane.org/gmane.os.cygwin.applications/25904 <pre> Are you asking because you use the get-cygwin-package script or because you were using it for your own personal uploads? If it is the former then that's a problem, I guess (I didn't think anyone was using the script since it wasn't foolproof). It is is the latter then you shouldn't have been using that area to begin with. It wasn't created for general use. cgf </pre> Christopher Faylor 2013-05-22T16:38:26 http://permalink.gmane.org/gmane.os.cygwin.applications/25903 <pre> any reason why /sourceware/snapshot-tmp/cygwin/release has been removed ? -bash-4.1$ cd /sourceware/snapshot-tmp/cygwin -bash-4.1$ ls -l total 2184 drwxrwsr-x. 4 cgf cgf 4096 May 14 2012 cvs-mirror -rw-rw-r--. 1 cgf cygwin 774 Mar 19 14:52 Makefile drwxrwxr-x. 2 root cygwin 4096 Jun 10 2009 RCS -rwxr-xr-x. 1 cgf cygwin 2220573 Apr 29 2012 setup.exe -bash-4.1$ Regards Marco </pre> marco atzeri 2013-05-22T16:05:29 http://permalink.gmane.org/gmane.os.cygwin.applications/25902 <pre> Uploaded. Yaakov </pre> Yaakov (Cygwin/X 2013-05-22T01:09:05 http://permalink.gmane.org/gmane.os.cygwin.applications/25901 <pre>BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7 wget --no-host-directories --force-directories --cut-dirs=5 \ ${BASEURL}/UGu_bsP8XW/64bit/release/doxygen/doxygen-1.8.4-1-src.tar.bz2 \ ${BASEURL}/ZRfN9VKFzW/64bit/release/doxygen/doxygen-1.8.4-1.tar.bz2 \ ${BASEURL}/07f8FokqQW/64bit/release/doxygen/setup.hint This is a minimal build of doxygen-1.8.4 for 64-bit Cygwin: * There is no TeX support in Cygwin64 at the moment, so you will need to specify 'GENERATE_LATEX = NO' in your doxygen configuration file. For the same reason, there is no PDF version of the manual in this build. * There is no libclang in Cygwin64 at the moment, so this build does not have the 'clang assisted parsing' feature that is present in the 32-bit version. * There is no Qt4 support in Cygwin64 at the moment, so this build is provided without the doxywizard sub-package. * Compiling with --ggdb produces a compilation error (too many sections) which I am unable to work around. Hence there is no debuginfo package for this build. I will rebuild doxygen when 64-bit versions of clang / Qt4 / texlive-collection become available. Cheers, Dave. </pre> David Stacey 2013-05-21T20:32:26 http://permalink.gmane.org/gmane.os.cygwin.applications/25900 <pre>Latest from CVS: New __b64_ntop/__b64_pton functions and patching cygpath and ps to use the right mbstowcs/wcstombs functions... Corinna </pre> Corinna Vinschen 2013-05-21T12:01:03 http://permalink.gmane.org/gmane.os.cygwin.applications/25899 <pre>[snip] Done and done. Yaakov </pre> Yaakov (Cygwin/X 2013-05-20T19:24:50 http://permalink.gmane.org/gmane.os.cygwin.applications/25898 <pre>BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7 wget --no-check-certificate --no-host-directories --force-directories --cut-dirs=4 \ ${BASEURL}/D5wIQxCe9e/release/doxygen/doxygen-1.8.4-1-src.tar.bz2 \ ${BASEURL}/7ldGx1Ng8M/release/doxygen/doxygen-1.8.4-1.tar.bz2 \ ${BASEURL}/S0WLMr_y8z/release/doxygen/setup.hint \ ${BASEURL}/7UyhsHmI7f/release/doxygen/doxygen-debuginfo/doxygen-debuginfo-1.8.4-1.tar.bz2 \ ${BASEURL}/o9JY-YlExo/release/doxygen/doxygen-debuginfo/setup.hint \ ${BASEURL}/VIVP0Hk5ih/release/doxygen/doxygen-doxywizard/doxygen-doxywizard-1.8.4-1.tar.bz2 \ ${BASEURL}/e6GGPYhIEC/release/doxygen/doxygen-doxywizard/setup.hint Please delete 1.8.2-1 and leave 1.8.3.1-1 as previous. 64-bit version to follow in a couple of days. Many thanks, Dave. </pre> David Stacey 2013-05-20T17:08:59 http://permalink.gmane.org/gmane.os.cygwin.applications/25897 <pre>2013/5/20 Yaakov (Cygwin/X): But why vi != vim? alternatives fixes this on Debian/Ubuntu. Why not use it on Cygwin? vim-7.3.762 used a update-alternative in its postinstall script when there was no conflict (at least not on my setup with X). But vim-7.3.943 doesn't have it anymore. alternatives is in base, it is made to solve these kinds of conflicts. Why did you stop using it now that the conflict really started to happen? Letting the postinstall scripts return with the proper priority fixes the problem. It works perfectly when I run it manually. The command "vi" is always available and automatically uses the best version of vim. My steps: renamed vi.exe to vim-minimal.exe renamed vim.exe to vim-nox.exe Run these commands: (add as postinstall scripts): /usr/sbin/update-alternatives \ --install /usr/bin/vim vim /usr/bin/vim-minimal.exe 10 \ --slave /usr/bin/vi vi /usr/bin/vim-minimal.exe \ --slave /usr/bin/view view /usr/bin/vim-minimal.exe \ --slave /usr/bin/vimdiff vimdiff /usr/bin/vim-minimal.exe \ --slave /usr/bin/rvim rvim /usr/bin/vim-minimal.exe \ --slave /usr/bin/rview rview /usr/bin/vim-minimal.exe /usr/sbin/update-alternatives \ --install /usr/bin/vim vim /usr/bin/vim-nox.exe 30 \ --slave /usr/bin/vi vi /usr/bin/vim-nox.exe \ --slave /usr/bin/view view /usr/bin/vim-nox.exe \ --slave /usr/bin/vimdiff vimdiff /usr/bin/vim-nox.exe \ --slave /usr/bin/rvim rvim /usr/bin/vim-nox.exe \ --slave /usr/bin/rview rview /usr/bin/vim-nox.exe Now vi links to the best vim available. $ /usr/sbin/update-alternatives --display vim vim - status is auto. link currently points to /usr/bin/vim-nox.exe /usr/bin/vim-minimal.exe - priority 10 slave rview: /usr/bin/vim-minimal.exe slave rvim: /usr/bin/vim-minimal.exe slave vi: /usr/bin/vim-minimal.exe slave view: /usr/bin/vim-minimal.exe slave vimdiff: /usr/bin/vim-minimal.exe /usr/bin/vim-nox.exe - priority 30 slave rview: /usr/bin/vim-nox.exe slave rvim: /usr/bin/vim-nox.exe slave vi: /usr/bin/vim-nox.exe slave view: /usr/bin/vim-nox.exe slave vimdiff: /usr/bin/vim-nox.exe Current `best' version is /usr/bin/vim-nox.exe. Add the corresponding preremove scripts: /usr/sbin/update-alternatives --remove vim /usr/bin/vim-minimal.exe /usr/sbin/update-alternatives --remove vim /usr/bin/vim-nox.exe Are there any reasons not to use this? Regards, Frank </pre> Frank Fesevur 2013-05-20T09:48:51 http://permalink.gmane.org/gmane.os.cygwin.applications/25896 <pre> Indeed; libglib2.0_0 should not require python-gobject; that was a false positive created by the gdb.py support files. I have removed this dependency on sourceware. Yaakov </pre> Yaakov (Cygwin/X 2013-05-20T08:36:44 http://permalink.gmane.org/gmane.os.cygwin.applications/25895 <pre> Not directly: syntax highlighting requires files from vim-common, which pulls in perl due to other perl scripts contained therein. The vim package still provides the huge feature set, now with the addition of lua/perl/python/python3/ruby support (dynamically loaded). Basically, if you want features, keep using vim. Otherwise, ex/vi (vim-minimal) provides the basic POSIX functionality. The big change is that vi != vim anymore. The workaround will be to use ~/.virc with vi. The bigger feature sets require the support files in vim-common, and *that* is the dependency which needs to be avoided for a minimal, Base-worthy ex/vi. Yaakov </pre> Yaakov (Cygwin/X 2013-05-20T08:25:24 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.cygwin.applications