SSH key for upload access
Name: Frank Fesevur Package: shutdown BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQCi5eVDKt69E7qYMI3wVuOjLnmn6GE6hCyDIchFud WSHKEwh9k1OwQ4fPZWfsyKDupQgcn4h0/QoIEHNQBIoqCrqvLAMeIDa+/I5lsxdiK1D1ZR y10zTgxfil6gA+1cjwFDLdqR1VM2V9HOCxMGKMFTwr+UY9ScFn0aCCZXC7QvnBf09IDXQz 5l2wCZfjRsj7N6IjFoWBmkF6WwUFAVNgZTAIwTK8ToOYsH452WEztlfvrlgyxM87atn2Ei iI0YqaCncQhSTXvEdHbc8IgBPUJWuw8iT0/8VQImbGwW8MAfd6tiCsNcflCuUtrz+pFaAt S0XBXLMazRPEPEYxLERmxB END SSH2 PUBLIC KEY
Re: Up for adoption: ctags and expat
2016-08-12 12:19 GMT+02:00 Corinna Vinschen: > On Aug 12 11:01, Frank Fesevur wrote: >> Universal ctags is the continuation of exuberant ctags. We have tried >> to convince Darren Hiebert (the original author of exuberant) to team >> up so we could keep the name. But that didn't work out, so we had to >> fork and came up with the name universal. > > Pity. Absolutely. >> I would say, make the switch to universal. I am willing to maintain >> that package. Question is how to update a package without official >> releases. And it hasn't been included in any major distro AFAIK. > > You could start with a test build and set the version numbers in the > setup.hint file explicitely. If it works out fine, you only have to > keep up with the prev/curr markers as long as "prev" is the exuberant > package. Question is, *are* there any version numbers yet? If not, > you could use git commit IDs for the time being. There is no version number yet. The expectation is it will become 6.0 so something like 5.9-date-shorthash could a temporary version number for a test release. The compile date and hash are shown when "ctags --version" is invoked. I just tried and the basic compilation of the current master branch works. Regards, Frank BTW. Did you know that a coworker of you is the lead developer of universal ctags? https://github.com/masatake
Re: Up for adoption: ctags and expat
2016-08-12 10:11 GMT+02:00 Corinna Vinschen: > Given the obvious lack of upstream development, did anybody try > to replace exuberant ctags with universal ctags? > > https://ctags.io/ > > I noticed that our co-maintainer Frank Fesevur is involved in this > project. Frank, any insight? I have been active in the development of universal ctags, but at the moment not too much. Universal ctags is the continuation of exuberant ctags. We have tried to convince Darren Hiebert (the original author of exuberant) to team up so we could keep the name. But that didn't work out, so we had to fork and came up with the name universal. My main reason to help out was to make sure it kept working on native Windows. I use ctags for a Notepad++ plugin I wrote. I have successfully compile universal ctags for cygwin a while ago and it worked. Not sure how it is at the moment. There have been some changes in the build files so not sure if cygwin still works. Pull request are always reviewed. Among many other improvements, universal ctags has more and better parsers. You can add your own parser with an external program or with regexs. You can write the output as JSON. There hasn't been any official release. ATM there is no-one working on that. Making all the docs up-to-date with all the development that has been going on is the biggest task. I would say, make the switch to universal. I am willing to maintain that package. Question is how to update a package without official releases. And it hasn't been included in any major distro AFAIK. Regards, Frank
Other repos to git? WAS Newlib/Cygwin now under GIT
2015-03-10 16:38 GMT+01:00 Corinna Vinschen: I'm happy to inform you that the move of Newlib/Cygwin from the src CVS repository to the new, combined GIT repository is now final. What is going to be the policy on cygwin-apps CVS repos? Are they going to be converted to git as well? I am working on a new version of shutdown. When the cygwin setup repo was converted to git I converted the small CVS shutdown repo to git and worked from there. At the moment my work in progress can be found at https://github.com/ffes/cygwin-shutdown but I gladly push that repo to sourceware as well. Or maybe the admin of sourceware wants to use this repo to set it up. Regards, Frank
Re: Other repos to git? WAS Newlib/Cygwin now under GIT
2015-03-11 16:45 GMT+01:00 Corinna Vinschen: Are you happy with github? If so, there's no reason to duplicate the repo on sourceware. We can just make the crusty CVS repo R/O. Or, if you rather switch to sourceware, I can mirror your github repo and then we simply define the sourceware repo as master repo. You have an account on sourceware anyway, afaics. I'm very happy with github. It is just that when I took over the package from you, you preferred the repo on sourceware. https://www.cygwin.com/ml/cygwin/2013-05/msg00311.html So if you don't mind, it fine to me to keep the new repo on github. Regards, Frank
Re: [HEADSUP] Moving setup sources to git
2015-02-10 14:55 GMT+01:00 Vin Shelton: git clone cygwin.com:/git/cygwin-setup.git Cloning into 'cygwin-setup'... Permission denied. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I assume that you (just like me) didn't have write access to the original CVS repo. This worked for me: git clone git://cygwin.com/git/cygwin-setup.git Regards, Frank
Re: [HEADSUP] Moving setup sources to git
2015-02-09 17:24 GMT+01:00 Corinna Vinschen: please don't check in anything to the setup CVS repo anymore. I just created a git repo for setup: git clone cygwin.com:/git/cygwin-setup.git Just to let you know that the anonymous read-only access works: git clone git://cygwin.com/git/cygwin-setup.git But I tried to build setup and I have a problem with the dependencies. README says I need various mingw libs. But if IIRC mingw is not recommended anymore. I have installed mingw64 and the mingw64 variants of those libs. But there is no mingw64 variant of liblzma. I've installed all 5 packages containing liblzma, but configure seems to be unable to find it. Do I still need the original mingw to compile setup or is the README outdated? Regards, Frank
Re: [HEADSUP] Moving setup sources to git
2015-02-09 20:46 GMT+01:00 Achim Gratz: HOW TO BUILD: - Setup should build out-of-the-box on any Cygwin environment that has all the required packages installed: - - mingw-gcc-g++ - make - - mingw-bzip2 - - mingw-libgcrypt-devel - - mingw-liblzma-devel - - mingw-zlib - - and all packages that are dependencies of the above, i.e. gcc-mingw-core, -mingw-runtime, binutils, w*api, etc. + - mingw64-gcc-g++ + - mingw64-bzip2 + - mingw64-libgcrypt + - mingw64-xz + - mingw64-zlib + - and all packages that are dependencies of the above - upx (optional) Thanks, mingw64-xz did the trick. Frank
Re: HEADSUP Maintainers: Stale packages on sourceware
2014-10-29 14:42 GMT+01:00 Yaakov Selkowitz: Please find attached a list of old package tarballs which are not listed anywhere in setup.ini, meaning that they are not listed as a previous, current, or test package, and cannot be installed with setup. These files consume a total of over 1.3Gib. Do maintainers have any objections to these being removed? No problem. Regards, Frank
[ITA] shutdown 1.10-1
Hi, As invited by Corinna to take over maintenance of the Cygwin shutdown package[1]. Since this is my first package could somebody please check it? wget --cut-dirs=2 -r -nH \ http://www.fesevur.com/downloads/cygwin32/shutdown/shutdown-1.10-1.tar.bz2 \ http://www.fesevur.com/downloads/cygwin32/shutdown/shutdown-1.10-1-src.tar.bz2 \ http://www.fesevur.com/downloads/cygwin32/shutdown/setup.hint \ http://www.fesevur.com/downloads/cygwin32/shutdown/shutdown-debuginfo/setup.hint \ http://www.fesevur.com/downloads/cygwin32/shutdown/shutdown-debuginfo/shutdown-debuginfo-1.10-1.tar.bz2 wget --cut-dirs=2 -r -nH \ http://www.fesevur.com/downloads/cygwin64/shutdown/shutdown-1.10-1.tar.bz2 \ http://www.fesevur.com/downloads/cygwin64/shutdown/shutdown-1.10-1-src.tar.bz2 \ http://www.fesevur.com/downloads/cygwin64/shutdown/setup.hint \ http://www.fesevur.com/downloads/cygwin64/shutdown/shutdown-debuginfo/setup.hint \ http://www.fesevur.com/downloads/cygwin64/shutdown/shutdown-debuginfo/shutdown-debuginfo-1.10-1.tar.bz2 Regards, Frank [1] http://cygwin.com/ml/cygwin/2013-05/msg00304.html
Re: [RFC] vim-minimal in Base?
2013/5/20 Yaakov (Cygwin/X): 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. Apart from that, I guess calling vi (and that's what *many* users are used to) will now result in the same error Frank reported. The workaround will be to use ~/.virc with vi. 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
Re: [RFC] vim-minimal in Base?
2013/5/14 Warren Young wrote: On 5/13/2013 21:28, Yaakov (Cygwin/X) wrote: As these utilities are required by POSIX[1], should the vim-minimal package be added to Base? As long as when I install vim-kitchensink setup.exe knows how to quietly replace vim-minimal, I'm happy to see Vim in Base. And the other way around? On existing installations it should not replace the full vim with the minimal one when it is added to Base. I expect I'll now find myself running vim-minimal for months on some boxes, purely because I got it by default and it's good enough. I had to do a clean installation today and installed vim-minimal. It worked fine for the occasional editing I needed to do. Thanks! Regards, Frank
Re: [RFC] vim-minimal in Base?
2013/5/14 Yaakov (Cygwin/X): Apart from that, yes, vim-minimal should be a Base package, finally ;) Done. It overrides the symlink from vi to vim.exe and so this breaks my current setup: $ vi Error detected while processing /home/Frank/.vimrc: line1: E319: Sorry, the command is not available in this version: syntax on Press ENTER or type command to continue Any thought other then fixing the symlink manually? Regards, Frank
Re: [RFC] vim-minimal in Base?
2013/5/14 Frank Fesevur: It overrides the symlink from vi to vim.exe and so this breaks my current setup: $ vi Error detected while processing /home/Frank/.vimrc: line1: E319: Sorry, the command is not available in this version: syntax on Press ENTER or type command to continue Raspbian and Ubuntu install vim.tiny and vi.basic executables and then use alternatives to avoid the conflict. I don't very little about alternatives, but I guess something similar must be possible on cygwin as well. Install them as vim.tiny.exe and vim.basic.exe (or whatever the right name is) and add a postinstall script to vim-minimal and update the existing postinstall script for vim. The /etc/postinstall/vim.sh.done currently on my system uses update-alternatives and refers to /usr/bin/vim-nox.exe but that is not in /usr/bin. The postinstall of vim.common refers to vim-nox.exe as well. And I assume the order of running the postinstall scripts is important. Regards, Frank
Re: [ITA] figlet 2.2.2 - Frank, Ian Glenn's Letters (large letters on text screen)
At 14-8-2007 8:38, Jari Aalto wrote: Did you see http://cygwin.com/ml/cygwin/2007-08/msg00319.html ? $ figlet -I1 20202 $ figlet -I2 fonts in contrast to $ figlet -I1 20200 $ figlet -I2 /usr/share/figletfonts Not sure what happened. I recompiled the sources. Please upload. Just to confirm, it is indeed fixed. Thanks, Frank
Re: Package maintainer list
At 25-7-2007 10:42, Corinna Vinschen wrote: Below are the lists of orphaned and maintained packages. I did not mention the obsoleted packages. I have a list of them on request. Please check the list for correctness. Please keep in mind that you're generously offered a gold star for every orphaned package you take over ;) I noticed that some of the orphaned packages, like gnutls and links, are in Cygwin ports http://cygwinports.dotsrc.org/ Regards, Frank
Re: [ITP] libssh2
At 28-6-2007 4:31, Brian Dessent wrote: I have been meaning up update the curl packages to 7.16.x for a while, however, I have held off because a new feature in curl is support for transfers over ssh (scp:// and sftp:// URLs.) However this support requires a recent libssh2, and until recently there had not been a release of this library in a while so that meant using a CVS version. libssh2 0.15 was finally released a couple of days ago, so I'd like to package it, then I can release updated curl/libcurl versions that use it. The project is relatively new as far as I know and not in any stable distro (but I haven't checked exhaustively), so it will likely need 5 votes. But, do you still need 5 votes if you need it for a new release of an existing package? Otherwise +1 for me. Regards, Frank
Re: setup.hints which mention Base in their category
At 6-6-2007 18:05, Corinna Vinschen wrote: On Jun 6 11:00, Christopher Faylor wrote: So the question is: Does this list look right. I'm not sure about brltty and gdbm. And I also wonder about ncurses, readline, and zlib. While they probably do get used by default anyway, I wonder why they have to be in Base. Is there a broken dependency somewhere? If not, it seems like they would be loaded automatically by anything in Base which needed them. I agree for gdbm and everything else which is basically a library (ncurses, readline, zlib). I don't care exactly for brltty, we can also put it into Utils. The two problems I mentioned on the list should be solved anyway. One other thing... brltty requires util-linux, which required perl. So now perl became part of Base. Regards, Frank
Re: Please upload exim-4.65-1
Pierre A. Humblet wrote: Please upload exim-4.65-1 from Just curious. Is there a reason to upload 4.65 and not 4.66 which is the current release on exim.org? Frank
Re: weft 0.4
At 30-10-2006 18:12, Dave wrote: Comments on the package itself: 1. You've created a C++ program that essentially is just writing to the registry. Have you considered scripting it instead? Then you can leave the registry handling to regtool. There were two main reasons for me to choose for C++: - I know I'm better with C++ then with bash scripts (it's always good to know your own limitations ;-) - When I saw the quoting nightmare (as you say in your own comment) you had to get the shell for the 'passwd', I knew when I write directly to the registry it would less of a problem. 2. You have hardcoded the bash invocation line. Sorry, but I don't understand it. I think it is because English is not my native tongue, but what do you mean with bash invocation line? It took a while to get it right with chere. Issues that you'll find with the invocation you're using: a) won't work on scripts in network paths b) won't play with ash or tcsh. Not a problem now since you're only supporting bash. The only reason I didn't add other shells yet, is because I don't have any experience with them. When you look at the code you see in SetShell() other shells can be added without much problems. c) I don't think this plays well with spaces or '$' in a path (but I could be wrong). Note '$' is commonly found in MS hidden network shares. It is no problem to start a script when spaces in the filename. I just tested and indeed it does not work when the script is on shares. 3. You're starting a login shell for every script you want to run. Probably fine on a modern machine, but there's always someone trying to eke out a performance gain. You got a point. More general: weft will manage invoking scripts (or programs) which do not require additional arguments directly from a particular shell. To add the ability to handle a type of extension that does not want to be executed by a shell (say for .pdf), the source of weft will need to be patched and recompiled (and run to add the handler). I don't know if many would want to do this with a cygwin app, but then again, many most people here in cygwin-apps don't feel the need to start a script from the Explorer. But I don't see the problem of this. It goes for almost any package that you need to recompile to add functions. And why not have an option to specify a path the start when you add an extension. My feeling is that we need to have a single package which manages all the explorer extensions anybody may want to add. I don't think the package as proposed can easily be made to do this. Sounds like a good idea to me. Together with the fact that I've never felt the need to execute a script directly from Explorer, weft doesn't get my vote as it stands. But when I look at the reactions I got IRL and the fact that is has been discussed on the lists before, I think enough people do like it. I know the 0.4 version is not yet a general releasable version. It does not have that version number for nothing ;-) I have a work in progress which could do the generic management of explorer extensions (see link below). As is typical, I haven't had time to perfect it - but by all means, have a look at what I've done and between us we might get this functionality into cygwin. I have looked through the archive before I started coding. I found the message I mentioned in my readme, but I missed that one :-( I don't mind to drop weft and help to make the new package. My reason to write is, was to have the functionality. It doesn't have to be weft if there is another/better way to do it. I will definitely take a closer look at your code. Just two minor remarks. I'm personally not that much a fan of tray icons. I already have way too much on my machine. And I don't think .xpi is a good extension as it is already used for Mozilla extensions. Regards, Frank
weft 0.4
Hi, Two weeks ago I sent a message to this list, but there wasn't any reply. http://cygwin.com/ml/cygwin-apps/2006-10/msg00029.html Regards, Frank
Re: weft 0.4
At 25-10-2006 23:00, Christopher Faylor wrote: On Mon, Oct 23, 2006 at 07:08:51PM +0200, Frank Fesevur wrote: Two weeks ago I sent a message to this list, but there wasn't any reply. http://cygwin.com/ml/cygwin-apps/2006-10/msg00029.html Sorry, but the lack of response probably means that no one is interested in your package. That doesn't bode well for your getting the votes required for it to be included in the distribution. I was afraid someone was gonna say that ;-) But I find it a kind of strange that no one would be interested in it. chere does similar things. It helps to integrate Cygwin and Windows. And AFAICT, chere is received quite well. But no hard feelings. I wrote the package, it fits my own needs. I thought that others could benefit from it as well. We install weft on every pc/server we need cygwin on. As I wrote in my readme, we use a lot of bash scripts on our Windows servers and often just by double clicking them in the Explorer. Regards, Frank
[ITP] weft 0.4
Hi all, I wrote a new package for cygwin. It is called weft, an acronym for Windows Explorer File Types. With weft you can attach an extension to bash. So it allows you to start a bash script by double clicking it from the Windows Explorer or any file manager of your choice. You can find it here: http://www.fesevur.com/cygwin/weft-0.4-1.tar.bz2 http://www.fesevur.com/cygwin/weft-0.4-1-src.tar.bz2 http://www.fesevur.com/cygwin/setup.hint I hope you like it and allow it to be a package in cygwin. Regards, Frank
