Re: Up for adoption: ctags and expat

On Aug 12, 2016, at 7:57 AM, Corinna Vinschen wrote: > > > Cool! If you want to take over ctags and test universal ctags for > Cygwin, feel free if Warren agrees. I'll change over maintainership > then. > > Warren, does that sound good to you? > > Doug, I hope you

Up for adoption: ctags and expat

I’m the current maintainer of these two packages. As it happens, I have never seriously used either under Cygwin. I only adopted ctags because it was abandoned in 2003 and was in danger of being removed from the distribution after repeated attempts to contact its maintainer in 2005 failed.

Re: [ITP] words - Dictionary file

On Jul 14, 2016, at 10:23 AM, David Stacey wrote: > >> the words package is more likely to be useful for any modern purpose. > > So are you happy for me to upload the 'words' package as it is at the moment? To the extent that I am a gatekeeper, sure. I think the real

Re: [ITP] words - Dictionary file

On Jul 13, 2016, at 7:30 AM, Marco Atzeri wrote: > >> This needs to be coordinated with Warren's proposal: >> >> https://www.cygwin.com/ml/cygwin-apps/2016-07/msg00015.html >> > the two packages seem to provide different word lists. Yes. The ‘words’ package’s source is the Moby Project,

Re: ITA: GNU miscfiles

On Jul 13, 2016, at 7:56 AM, Corinna Vinschen wrote: > > when using dodoc it should better point to the source file The problem is that the GNU-manifesto file is installed, but in the wrong location, IMHO. I was hoping that dodoc would be smart enough to realize

Re: ITA: GNU miscfiles

On Jul 13, 2016, at 6:58 AM, Ken Brown <kbr...@cornell.edu> wrote: > > On 7/13/2016 7:05 AM, Corinna Vinschen wrote: >> On Jul 12 11:06, Warren Young wrote: >>> CATEGORY=Misc > > This is not a legal category. Sorry, I used it because setup.exe shows that as

Re: ITA: GNU miscfiles

On Jul 12, 2016, at 11:06 AM, Warren Young <w...@etr-usa.com> wrote: > > NAME=miscfiles > VERSION=1.5 > RELEASE=1 Late addition: ARCH=noarch

ITA: GNU miscfiles

Per https://cygwin.com/ml/cygwin/2016-07/msg00160.html …I would like to adopt the GNU miscfiles package. I have constructed the following cygport file, which seems to do the trick: NAME=miscfiles VERSION=1.5 RELEASE=1 SUMMARY="Miscellaneous data files"

Bug in fontconfig postinstall script: spaces in *.ttf

The zp_fontconfig_cache_1.sh postinstall script links all *.ttf fonts in $(cygpath -W)/Fonts that contain “Microsoft Corp” into /usr/share/fonts/microsoft. This script creates broken links when such a font contains a space in its filename, as happens with SketchFlow\ Print.ttf on my system.

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

On Jun 6, 2016, at 4:23 PM, Yaakov Selkowitz wrote: > > So far we have managed to reduce the download area by 20% (16.8 GiB) Nice! > which is great progress The next step, of course, is allowing multi-arch packages, so you can upload the -doc subpackage as noarch and

Re: [RFC] /etc/shells management (fish, mksh, posh, tcsh, zsh)

On May 12, 2016, at 3:36 PM, Yaakov Selkowitz wrote: > > What are the consequences of having shells listed in /etc/shells which aren't > on the system? That file is a security feature, but the typical way Cygwin works — i.e. that normal users are allowed to install

Re: [SECURITY] cygwin32-expat, mingw64-$arch-expat, etc.

On Mar 16, 2016, at 2:32 PM, Yaakov Selkowitz <yselkow...@cygwin.com> wrote: > > On 2016-03-16 14:28, Warren Young wrote: >> expat 2.1.1 fixes MEDIUM-rated CVE-2015-1283. I’ve uploaded the regular >> expat 2.1.1 packages, but the cross-development packages maintai

Re: [ITP] procps-ng

On Mar 16, 2016, at 2:18 PM, Wayne Porter wrote: > > It contains free, kill, pkill, pgrep, pmap, ps, pwdx, slabtop, sysctl, > tload, top, uptime, vmstat, w, and watch” Is the intention for this to replace the current procps package, or to be an alternative? If the latter,

[SECURITY] cygwin32-expat, mingw64-$arch-expat, etc.

expat 2.1.1 fixes MEDIUM-rated CVE-2015-1283. I’ve uploaded the regular expat 2.1.1 packages, but the cross-development packages maintained by Yaakov are all at 2.1.0. Some appear to have 2.1.1 alternate versions available

Re: [ITP] libSBML-5.12.0-core and moose-3.0.2

On Mar 5, 2016, at 6:22 AM, Achim Gratz wrote: > > Corinna Vinschen writes: >> More important to me is that the maintainer-to-be subscribes to the >> cygwin user mailing list as well as the cygwin-apps maintainer mailing >> list and promises to scna the list for user problems

Re: [ITP] The Silver Searcher / Ag

On Feb 23, 2016, at 7:42 AM, Adam Dinwoodie wrote: > > I'm looking at packaging The Silver Searcher, aka Ag. That would be lovely! I’ve been building it from source since I discovered it, about a year ago. (Anyone still using grep -R on a source tree really should switch

Re: Changing Setup's license to GPLv3+

On Jan 22, 2016, at 9:54 AM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > > On Jan 21 15:55, Warren Young wrote: >> On Jan 21, 2016, at 3:49 AM, Corinna Vinschen <corinna-cyg...@cygwin.com> >> wrote: >>> >>> does anything speak against sw

Re: Changing Setup's license to GPLv3+

On Jan 21, 2016, at 3:49 AM, Corinna Vinschen wrote: > > does anything speak against switching Setup's license to GPLv3+? > If nobody complains, I'll bump to v3+ in a week or so. Can you actually do that, legally? I thought the copyright assignments only applied to

Re: Attn gawk and man-db maintainers: 3am pages shadowing 3p

On Oct 23, 2015, at 1:18 PM, Yaakov Selkowitz wrote: > > On Linux, 'man readdir' gets you readdir(2) (the kernel system call), > which promptly states: > >This is not the function you are interested in. Look at readdir(3) >for the POSIX conforming C library interface. Interesting, but

Attn gawk and man-db maintainers: 3am pages shadowing 3p

Several gawk module manual pages (fnmatch, fork, readdir, and time(3am)) currently shadow pages of the same name in section 3p, owned by man-pages-posix. These are currently dumped into the generic man3 directory, which causes them to take precedence over 3p because of this line in

Re: setup.exe not logging on Windows 10 with MS accounts

On Oct 15, 2015, at 2:29 PM, Warren Young wrote: > > Achim Gratz noted that my default permissions may be weird because I am > running with a Microsoft Account rather than a local one. I just poked a hole in that theory last night: I have a Windows 8 VM at home that also uses a M

setup.exe not logging on Windows 10 with MS accounts

In another thread [1] I discovered that setup.exe hasn’t logged anything to /var/log/setup.log since November 2014, despite running it occasionally during that time. I have ruled out permission problems, since I can write to that file as both a normal user and from an admin shell. The latter

Re: setup

On Aug 11, 2015, at 1:47 AM, Corinna Vinschen wrote: On Aug 10 09:02, Warren Young wrote: If you mean that it always copies itself to some kind of temp space and execs it from there, that feels kind of wasteful ...the restart part is done already anyway as soon as setup elevates itself

Re: setup

On Aug 10, 2015, at 10:40 AM, Achim Gratz wrote: Warren Young writes: In that sense, setup.exe is already bootstrapped: it has everything within itself to be able to replace itself. I do like the concept of a self-contained executable, but teaching setup.exe new tricks is likely

Re: setup

On Aug 7 15:05, Warren Young wrote: You’d have to couple this either with a MoveFileEx(…, MOVEFILE_DELAY_UNTIL_REBOOT) call or a background task that replaces /bin/setup.exe with %LOCALAPPDATA%/Temp/setup-v$next.exe. Why? I was assuming a world where setup.exe lives in /bin and you can

Re: setup

On Aug 10, 2015, at 12:03 PM, Achim Gratz wrote: There have been a bunch of attempts in the past at replacing setup.exe. At least 3, that I can think of. All have fizzled. These were? The Debian and Red Hat packaging systems have both been ported to Cygwin. Those could be used along

Re: setup

On Aug 10, 2015, at 11:00 AM, Achim Gratz wrote: Warren Young writes: Isn’t the whole point of this discussion that setup.exe already knows all the tricks it needs to in order to do what we want here, except for the “replace setup.exe in place” issue I’ve brought up separately? Well

Re: setup

On Aug 7, 2015, at 11:22 PM, Achim Gratz strom...@nexgo.de wrote: a minimal Cygwin install system w/ busybox Busybox isn’t going to be usable in its normal sense without cygwin1.dll to map symlinks to argv[0] so that Busybox can tell how it was called, and thus which function to provide.

Re: setup

On Aug 7, 2015, at 1:47 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 6 17:57, Achim Gratz wrote: I would consider this a release candidate. Some more testing with interactive and ad-hoc installs would be useful, though. I have a vague idea that setup should ideally be

Re: missing 64bit ports

On Jul 15, 2015, at 8:24 AM, Marco Atzeri marco.atz...@gmail.com wrote: I spent a bit of time checking the real situation of the packages still missing as 64 bit port. Thank you for doing this research. ...we are down to ~44. ...half of them are dead upstream so we can directly obsolete

Re: missing 64bit ports

On Jul 15, 2015, at 11:39 AM, Marcos Vives Del Sol socram8...@gmail.com wrote: Reason I didn't port libnfc was because I lost my SSH key due to a hard drive crash. Any procedure on how to get a new one so I can compile and upload it? $ ssh-keygen I assume those in charge of maintaining the

Re: missing 64bit ports

On Jul 15, 2015, at 12:28 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - Shall we remove all 32b-bit only orphaned packages for which we don't get a maintainer until, say, end of August? If a package is available only for 32-bit, there should be a place to learn that prior to

Re: [HEADSUP] Dropping libopenssl098 from distro

On Apr 20, 2015, at 3:40 PM, Peter A. Castro doc...@fruitbat.org wrote: the machine I had access to disappeared a month ago and I've been scrambling to get another one. VirtualBox and the Windows 10 Technical Preview are free, and they run Cygwin just fine. :)

Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]

On Mar 4, 2015, at 6:11 PM, Eric Blake ebl...@redhat.com wrote: On 03/04/2015 02:41 PM, Andrew Schulman wrote: Huh? The plush hippos are always pink! Awarded! http://cygwin.com/goldstars/#CV Should I get anything for taking the orphaned grep/gperf/bison/diffutils/gzip when cgf left?

Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]

On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency? Hey, shall we move from goldstars to plush hippos? The standard solution is higher denominations. So, we need

Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]

On Mar 3, 2015, at 1:25 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Mar 3 13:23, Warren Young wrote: On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency

Re: [HEADSUP] Moving setup sources to git

On Feb 9, 2015, at 9:24 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: I just created a git repo for setup: About blinkin’ time. But it should have been Fossil. ;)

Re: cmake update needed

On Feb 4, 2015, at 3:40 PM, Tony Kelman t...@kelman.net wrote: Happy to adopt it. BASEURL=https://dl.dropboxusercontent.com/u/8244638/cygwin-cmake By “adopt,” you are offering to participate in the package contribution system, which involves a bit more than just putting tarballs in a

Re: User manual cleanup

On Dec 11, 2014, at 3:03 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Dec 10 16:34, Warren Young wrote: I kind of thought I’d been kicked off that project, after leaving the autodep stuff hanging. :) I'd never have kicked you out. Contrary to that, I was disappointed that you

Re: [HEADSUP] Base category

On Dec 10, 2014, at 4:05 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: It boggles my mind how much is in the Cygwin package repository, and then how much more is in Ports. To some extent, this has to be a reflection of Sturgeon’s Law. [2] Isn't that the same for all distros?

Re: [HEADSUP] Base category

On Dec 9, 2014, at 3:48 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Dec 8 15:28, Warren Young wrote: I’ve got in mind the 2-3 times in my memory where Perl has crept into the minimal install set via some indirect dependency. I still don't grok why everybody is so hot

apache2 package should depend on libapr1-devel and libaprutil1-devel

I know it sounds strange, but the httpd2-config script that comes with Cygwin's apache2 package calls apr-1-config and apu-1-config, which live in the -devel packages, being pkg-config type tools. Another solution would be to extract these *-config scripts into separate packages, and make

Re: Package categorization inconsistencies

On 1/24/2014 02:32, Corinna Vinschen wrote: Nothing to worry about I guess. I posted mainly for the maintainers, who may want to change their setup.hint files before their next upload.

Package categorization inconsistencies

While doing my how big is a full Cygwin installation research[*], I came across some inconsistencies in package categorization: perl_debuginfo: Not in the Debug category. It is also the only package named *_debuginfo instead of *-debuginfo cdrkit-doc, fftw33-doc, flac-docs, gsl-doc,

Re: [ITA] tcl-sqlite3

On 1/14/2014 05:44, Corinna Vinschen wrote: Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora is wrong, not following TEA? It's much easier to grok and doesn't wrongly imply it only works on a specificx

Re: [ITA] tcl-sqlite3

On 1/13/2014 03:57, Jan Nijtmans wrote: I assume someone (other than Warren Young) uploaded it as part of the Cygwin64 bootstrap process. Yep, not me. Probably Yaakov. I'm not sure if a GTG is needed from another package maintainer, If you've written a new .cygport file, I think you

Re: [ITA] sqlite3

On 11/14/2013 12:27, Christopher Faylor wrote: Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. Jan sent me a link to his proposed packages, which I looked at briefly, but they've disappeared.

Re: [ITA] sqlite3

On 11/15/2013 06:38, Warren Young wrote: On 11/14/2013 12:27, Christopher Faylor wrote: Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. GTG. I tested by unpacking the 3 main packages (exe, lib

Re: [ITA] sqlite3

On 11/13/2013 08:18, Christopher Faylor wrote: On Wed, Nov 13, 2013 at 04:03:40PM +0100, Jan Nijtmans wrote: I would like to adopt sqlite3. I've packaged the latest release. I don't think the package is in need of adoption. Warren Young is still around and active, AFAICT. Jan has been

SSH key for upload access

Name: Warren Young Package: sqlite3 SSHkey: ssh-rsa B3NzaC1yc2EBIwAAAQEAqBYtYozG/QWEHiPmTjomT2Q6gTf5mqCxonE5JoG7HJljb4dGColaOhv1rgDjctARI5ESkXOHhhcAHt25S/gZM21+MrBYjqar9eUm3q6yXlc+XLQiNrMpfOduFuKQAWMm4d6wE0KH3iU8DUfSxXc3n8tHIYhdJc7/x3qEwS59PqhOe9hA6OV+8Sf

Re: libtool ../bin hack for cyg*.dll not working

On 10/14/2013 01:47, Peter Rosin wrote: On 2013-10-11 23:52, Warren Young wrote: $ make libsqlite3.la $ ./libtool --mode=install install libsqlite3.la /usr/local/lib Works just fine for me. Thanks for testing. It turned out to be something screwed up in the local build system

libtool ../bin hack for cyg*.dll not working

libtool has long had a hack that causes it to install cyg*.dll into bindir instead of libdir by appending /../bin to the end of the installation directory. While trying to get SQLite 3.8.1 working on Cygwin, I've found that this isn't working any more. (It did work in SQLite 3.7.17.) I've

Re: libevent-2.0.21

On 10/4/2013 09:07, Chris Olin wrote: is there a process to have it brought into Cygwin so then all that I really need to do is package tmux and send out an ITP? You can adopt the libevent package yourself, which relieves Yaakov -- who maintains Cygwin Ports -- of the burden of maintaining

Re: libevent-2.0.21

On 10/4/2013 10:12, Chris Olin wrote: On 04/10/13 at 09:15am, Warren Young wrote: libevent is in Cygwin Ports to satisfy cyphertite, ocaml-libevent, and transmission. So, before adopting it, think about whether you want to place yourself in a blocking position for those packages, To clarify

Re: questions on using cygport, first steps

On 9/11/2013 10:01, Yue Ren wrote: $ cygport Singular-4-0-0.cygport compile Why did you start with 'compile'? I mean, what documentation did you read that lead you to believe that's the correct starting point? (I'm assuming you *did* RTFM: /usr/share/doc/cygport/manual.html.) The

Re: sqlite3

On 8/22/2013 23:54, Michael DeByl wrote: Sorry to be a pain Well, here's your pain returned: This should be on the main Cygwin mailing list, not the -apps list. :) (This list is for discussing the *packaging* of the Cygwin apps you use, not for discussing the use of them.) But since I

[RFU] expat-2.1.0-3

This release simply fixes the libexpat${abi}-devel naming problem brought up by Yaakov, using the new PKG_OBSOLETES feature of cygport. It includes no upstream release changes, because there haven't been any. From within x86/release/expat: wget -e robots=off --cut-dirs=3 -np -nH

Re: [RFC] cygport: PKG_OBSOLETES

On 7/25/2013 22:31, Warren Young wrote: On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote: On 2013-07-25 14:50, Warren Young wrote: I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it. It's in git master already. $ git clone git://cygwin

Re: [RFC] cygport: PKG_OBSOLETES

On 7/25/2013 02:30, Corinna Vinschen wrote: On Jul 24 14:38, Warren Young wrote: On 7/24/2013 05:41, Corinna Vinschen wrote: On Jul 24 05:12, Warren Young wrote: You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would

Re: [RFC] cygport: PKG_OBSOLETES

On 7/25/2013 15:33, Ken Brown wrote: could you provide a setup.hint for libexpat1-devel (64 bit)? Without a setup.hint, it gets put into the Misc category and is then installed by default. I don't know what you're talking about. Here's the setup.hint I RFU'd: category: Libs requires:

Re: [RFC] cygport: PKG_OBSOLETES

On 7/25/2013 17:36, Ken Brown wrote: Here's your RFU: wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \ http://etr-usa.com/cygwin64/expat/ Oh, it's one of *those*. My more recent RFUs include -A'*.hint' in the command. The *.hint files are all there on the server, if you want

Re: [RFC] cygport: PKG_OBSOLETES

On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote: On 2013-07-25 14:50, Warren Young wrote: I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it. It's in git master already. Cool. I will try to make use of this feature before your next release, but don't hold

[RFU 64-bit] sqlite3-3.7.17-3

Leave 3.7.16.2-1 as curr. From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.17-3*' -A'*.hint' \ -r http://etr-usa.com/cygwin64/sqlite3/ (These are the same as the 32-bit packages, released over a month ago. I just forgot to do the 64-bit ones after I decided

Re: [RFC] cygport: PKG_OBSOLETES

On 7/23/2013 13:11, Yaakov (Cygwin/X) wrote: But libexpat1-devel is a BAD choice of name, You're only having a problem with -devel, right, not the library package proper? Does this .cygport file solve the problem? DESCRIPTION=Expat XML parser library

Re: [RFC] cygport: PKG_OBSOLETES

On 7/24/2013 04:06, Corinna Vinschen wrote: Regardless of libexpat1-devel supposedly being a bad choice of names, from the global distro perspective, it would be much easier to remove the libexpat-devel package from the 64 bit distro and go over the hint files manually for now. Doesn't the

Re: [RFC] cygport: PKG_OBSOLETES

On 7/24/2013 05:41, Corinna Vinschen wrote: On Jul 24 05:12, Warren Young wrote: You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update. If you're willing to do

Re: sqlite defect

On 7/12/2013 12:49, fger...@gmx.de wrote: But since 3.7.17-3 I cannot read my databases any more unable to open datase file. Without a test case, debugging this will amount to testing guesses. My first guess: try setting the new CYGWIN_SQLITE_LOCKING environment variable to posix. That can

Re: sqlite defect

On 7/17/2013 18:27, Christopher Faylor wrote: Why was this thread redirected to cygwin-apps? The thread started here, and I replied here. David Rothenberger tried to redirect it to the main list.

Re: [RFU] sqlite3-3.7.17-3

On 6/14/2013 01:54, Corinna Vinschen wrote: On Jun 13 16:54, Warren Young wrote: Would someone flip this package from test to curr for me, please? Leave 3.7.16.2-1 as prev. Done. Thanks! Do you want to keep 3.7.13-1? I didn't know I could have more than one prev. Sure, let's keep

Re: [RFC] cygport documentation

On 6/13/2013 13:50, Achim Gratz wrote: a tutorial or similarly styled explanation of how to use cygport, That, or a recipe format, or a FAQ format. That is, one that starts with how, rather than what. it would probably help if the manual was called a reference to tone the expectations

Re: [RFU] sqlite3-3.7.17-3

Would someone flip this package from test to curr for me, please? Leave 3.7.16.2-1 as prev.

Re: [RFU] sqlite3-3.7.17-3

On 6/11/2013 01:37, marco atzeri wrote: you should make it test adding the relevant prev/current/test entries as specified on http://cygwin.com/setup.html Is there a way to set this via the .cygport file? I tried searching its HTML manual, and didn't find one. The alternative is to

[RFU] sqlite3-3.7.17-3

Leave 3.7.16.2-1 as curr, and make this test only for now. (I am hoping to be able to promote it to curr later, but it changes too much to risk that without more testing. The only reason I'm RFU'ing it is because there seems to be some resistance to installing test versions from raw

Re: [RFC] vim-minimal in Base?

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. Yes, truly happy. Gone are

Re: [RFC] vim-minimal in Base?

On 5/14/2013 04:19, Frank Fesevur wrote: Any thought other then fixing the symlink manually? I fixed it with alias vi=vim in my .bashrc. I've had to do that on assorted Linuxes before, too.

Re: New packages: Cygwin 32-to-64bit cross-compiler

On 5/10/2013 16:31, Yaakov (Cygwin/X) wrote: I just uploaded a x86_64-pc-cygwin target cross-toolchain for the i686 distro together with ~70 sysrooted libraries. Spiffy. Is there work underway to make cygport understand how to generate 32- and 64-bit packages at the same time? Or even a

Re: cygport-0.12.0-1: too many arguments

On 5/2/2013 07:34, Dr. Volker Zell wrote: While packaging the 64bit version of Xfig and transfig I get the following errors from cygport. Stripping executables: usr/bin/xfig.exe /usr/share/cygport/lib/src_postinst.cygpart: line 860: [: too many arguments What do you get for $

Re: HELP with Cygwin docs needed

On 4/23/2013 09:20, Corinna Vinschen wrote: does anybody know sgml and xmlto? I see that you've solved the problem, but maybe this is a good excuse to switch all these SGML files to DocBook XML (DBX)? I've taken a quick glance at this subtree. I think you can replace doctool with

Re: HELP with Cygwin docs needed

On 4/24/2013 11:20, Corinna Vinschen wrote: - What is the advantage of changing the format? Actually, a bit more looking makes me wonder if the docs actually *are* still SGML. All the processing now seems to go through xmlto, rather than OpenJade. Without digging through the CVS history,

Re: HELP with Cygwin docs needed

Forgot to update the footnote references: On 4/24/2013 12:31, Warren Young wrote: probably switch from the nonstandard doctool to XIncludes. [1] The GNOME docs are split between DocBook XML and SGML[1]. [2]

Re: HELP with Cygwin docs needed

On 4/24/2013 12:52, Corinna Vinschen wrote: So, if XInclude is not in the distro XInclude isn't a program, it's typically a feature of an XSLT processor. (It's not part of XSL or XSLT, so it could live elsewhere in some toolchains.) XInclude support has been in xsltproc since 2001, and

Re: [RFU 64bit] sqlite3-3.7.16.2-1

On 4/19/2013 03:32, Corinna Vinschen wrote: Just a tiny hiccup: The sqlite3 package has libncurses10 in the requires line, but the 64bit release only provides libncursesw10. Just, FYI. Yaakov fixed that on cygwin.com. I've fixed this by making use of Cygport's new setup.hint generation

[RFU 64bit] sqlite3-3.7.16.2-1

From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin64/sqlite3/

[RFU] expat-2.1.0-2

This just adds the missing .a file to the libexpat1-devel package. The other file size differences are no doubt due to toolchain changes over the past ~10 months since I built the -1 packages. (Upstream hasn't changed in that time, so I'm building from the same sources.) Remove the -1

[RFU 64bit] expat-2.1.0-2

This is a straight rebuild of the just-RFU'd 32bit build. Its test suite runs without errors and the resulting xmlwf(1) binary runs. I won't consider it properly tested until one of the Cygwin programs depending on it builds against it and runs, however. While in the release/expat

[RFU 64bit] ctags-5.8-1

This is just a straight rebuild of the existing 32-bit ctags-5.8-1. While in the release/ctags directory: wget -e robots=off --cut-dirs=2 -np -nH -A'*5.8-1*' -A'*.hint' -r \ http://etr-usa.com/cygwin64/ctags/

[RFU 32bit] sqlite3-3.7.16.2-1

Leave 3.7.13-1 as prev, and remove 3.7.3. From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin/sqlite3/ (I'm including the *hint files this time, Corinna. :) )

Re: Maintainers please weigh in on 64-bit Cygwin

On 3/17/2013 10:45, Christopher Faylor wrote: So, I'd appreciate some discussion about this. Last time I answered one of your RFCs, I got accused of bikeshedding. (This was the Win9x EOL issue, a month or so ago. I'm not sure whether the accusation was directed at me personally, or if I

Re: nuke cygwin legacy?

On 2/5/2013 10:41, Christopher Faylor wrote: Corinna +1'ed my suggestion that it was time to remove cygwin 1.5 support so I'm wondering if anyone has any objections to removing 1.5 from cygwin.com. It seems to me that the sort of person who's still hanging onto a DOS-based version of Windows

Re: sqlite3-3.7.15-1 test packages

On 11/21/2012 12:01, Achim Gratz wrote: FWIW, I think Yaakov is more immediately concerned about the additional API: -DSQLITE_ENABLE_COLUMN_METADATA\ -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS_PARENTHESIS\ -DSQLITE_ENABLE_FTS4 I've made some SQLite 3.7.15.1-1 packages, and put them up

Re: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]

On 12/12/2012 02:39, Corinna Vinschen wrote: Oh boy, how long do we have this collisions? For years, it seems. There must be a database of package contents behind the packages search engine on sourceware. If someone that has access to that DB extracts a raw list of file names, this command

Re: HEADSUP: lesstif replaced by motif

On 11/26/2012 05:28, Jon TURNEY wrote: The initial output to the gdb window stops before the 'ü' in Dorothea Lütkehaus (internally this is ISO-8859-1 encoded and presumably forms an invalid UTF-8 sequence) Only the 7-bit ASCII subset of ISO 8859-x is legal UTF-8. This is listed in the ddd

Re: LICENSE: base-files and use of CC0 - public domain

On 10/25/2012 11:49 AM, Jari Aalto wrote: Neither OSI, nor FSF recommend use of public domain for Open Source software. I think you should total up the list of recommendations the FSF has made over the years, and decide if you really want to be constrained use only things that make FSF

Re: LICENSE: base-files and use of CC0

On 10/25/2012 12:43 AM, Jari Aalto wrote: According to: git clone git://github.com/dsastrem/base-files.git base-files.git May files are put out using CC0 license[1]. I'm wondering this as it is to my understanding recommended only for data (images, pure data files, databases etc.), or

Re: ITP: xlsx2csv -- Convert xslx xml files to csv format

On 10/13/2012 1:59 PM, Jari Aalto wrote: Not yet included in any distributions, so needs votes. GTG. I hope you can work with the upstream author to fix the hexbarf version number, though. Does upset know how to cope with such version numbers, or will manual maintenance of prev:,

Re: get-cygwin-package - for anyone with upload privileges

On 10/17/2012 4:46 PM, Christopher Faylor wrote: I've hacked at the get-cygwin-package script I take it this script is run by hand when a human has decided to do something about an RFU message? If so, is there a plan or even a wish for getting to a point where a script can run on

Re: upload protocol

On 10/10/2012 11:46 AM, David Stacey wrote: As a newbie, I didn't know whether to wait for more comments, or to submit a [RFU] (as I'd been given a GTG) All of the discussion was questions of whether, not how or why. So, I think you should have just made the changes you wanted to make, and

Re: [ITP] doxygen-1.8.0-2 -- A documentation system for C++, C, Java, Objective-C, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D.

On 10/2/2012 1:10 PM, David Stacey wrote: On 02/10/12 02:27, Warren Young wrote: You should keep using -1 for subsequent build attempts Apologies for that. I was following the advice here: http://cygwin.com/setup.html#submitting I was sure I'd seen Corinna complain about a -1 to -2 during

Re: [ITP] doxygen-1.8.0-2 -- A documentation system for C++, C, Java, Objective-C, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D.

On 9/29/2012 1:21 PM, David Stacey wrote: wget \ http://www.drstacey.talktalk.net/doxygen-1.8.0-2.tar.bz2 \ http://www.drstacey.talktalk.net/doxygen-1.8.0-2-src.tar.bz2 \ http://www.drstacey.talktalk.net/setup.hint \ http://www.drstacey.talktalk.net/md5.sum You should keep using

Re: [PATCH] setup.exe build instructions outdated; build doesn't bootstrap cleanly

On 9/13/2012 5:09 AM, Jon TURNEY wrote: On 13/09/2012 03:23, Warren Young wrote: 5. Several build system files refer to iniparse.h, but on my system, iniparse.yy yields iniparse.hh, not .h. See the note on a Slightly backward-incompatible change in the section Changes to Yacc and Lex support

  1   2   3   >