Re: Up for adoption: ctags and expat

[Warren Young]

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 don't feel overlooked.  Expat is still yours if
> Warren has no problems with that.

Sounds like a plan.

Up for adoption: ctags and expat

[Warren Young]

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.  Since I do use ctags on other platforms,
I decided that I was at least in a position to keep it in Cygwin,
so I adopted it.  The situation was less drastic with expat: I simply
took over the package’s maintenance when Brian Dessent stepped down
in 2008.

The time has come for someone else to maintain these packages.

But not just anyone.  I do not want to drop another twig onto the
back of someone who’s already carrying a lot for the Cygwin project.
I’d prefer that these packages to go to someone who’s been looking
to jump into Cygwin package maintainership, and has just been waiting
for an excuse. 

These two are a mixed bag when it comes to ease of maintainership, 
each for very different reasons.

The easy part with ctags is that there hasn’t been an upstream 
release since 2009, and there is no reason to expect that there will 
be another.  The hard part is that the shipped Makefile doesn’t
understand how to do out-of-tree builds, something Cygport expects
to be able to do, so I had to write a custom build script to produce 
the current packages, which might have to be adjusted by the next
maintainer of this package, if a new version comes out with the same
primitive build system. 

As for expat, the easy part is that it builds out of the box under
Cygport, and I’ve already worked out the .cygport file for you, so a
new maintainer should have a very easy time with that part of the job.
The only difficult bit is that there has been a recent flurry of 
security patches to it, which makes building it more difficult than 
if you were just building from upstream release tarballs.  That said, 
it’s been a while since the last one, so maybe this is the beginning 
of another of the long lulls expat seems to go into.

If no such person steps up, I will stay on as maintainer.

Re: [ITP] words - Dictionary file

[Warren Young]

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 question is whether anyone wants miscfiles now.

Re: [ITP] words - Dictionary file

[Warren Young]

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, released into the 
public domain in the mid-1990s:

  https://en.wikipedia.org/wiki/Moby_Project

The words file in my package comes from an out-of-copyright edition of the 
Merriam-Webster dictionary from the 1920s.

Therefore, the words package is more likely to be useful for any modern purpose.

Much of the rest of the contents of the miscfiles package is also quite 
outdated.  Some of it is continually-changing information that hasn’t been 
touched in a decade or so.

The only thing I see in it that I think might actually be useful are the ASCII, 
Latin-1 and UTF-8 tables, which are useful on Cygwin since its manpages don’t 
include equivalents, as many other *ixes do.  But that said, I think I’d rather 
just have the man pages, since I’ve gotten into the habit of saying “man ascii” 
and such.

Re: ITA: GNU miscfiles

[Warren Young]

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 that 
I’m asking it to relocate this file within the inst tree.

>  Also, why not use a symlink as for the other file?

Because I don’t want /usr/share/misc/GNU-manifesto to exist at all.

Re: ITA: GNU miscfiles

[Warren Young]

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 a category here.  But on 
looking at the category’s contents, everything looks like packages I downloaded 
long ago, which have since been removed.

I also used it because nothing else looked suitable.  The next closest ones I 
see (Database and System) are quite a stretch.

Honestly, Base seems to fit better, but then of course we have to decide if 
this is really something that needs to be in Base.

>>> The last line in my src_install() override seems heavy-handed.
>> 
>> You only explain what you expect, but left out the interesting point
>> what actually happens.
> 
> He's trying to move GNU-manifesto from one directory under ${D} to another. 

Yes.  The normal “make install” rules put GNU-manifesto in the same directory 
as all the other files, when it should be off in the doc dir.  Apparently 
cygport’s rules for finding such doc files (e.g. README, COPYING, etc.) doesn’t 
include this name.

> He should just use 'mv'.

It’s not that simple.  This doesn’t work:

 mv ${D}/usr/share/misc/GNU-manifesto ${D}/usr/share/doc/${PN}

because /usr/share/doc doesn’t exist in the inst dir, so you get an error from 
mv.  Fixing that involves replacing two short lines of code with two longer 
lines, plus I’m reinventing part of the dodoc wheel.

I think I’ll just stick with dodoc + rm.

> 'dodoc' copies, it doesn't move.

Well, maybe it *should* move if the source file is also under the inst 
directory.  What would be the point of shipping two copies of the same file in 
a package?

Re: ITA: GNU miscfiles

[Warren Young]

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

[Warren Young]

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"
HOMEPAGE="https://www.gnu.org/software/miscfiles/;
SRC_URI="https://ftp.gnu.org/gnu/${PN}/${PN}-${PV}.tar.gz;

CATEGORY=Misc
DESCRIPTION="This is the GNU Miscfiles package, which is a collection
of files not of crucial importance for system administration or
operation, but which have come to be common on various systems over the
years. It includes data files for country codes, airport codes, currency
information, and so on."

CYGCONF_ARGS="--datarootdir=/usr/share/misc"

src_install() {
cd ${B}
cygmake -j11 DESTDIR=${D} install

dodir /usr/share/dict
dosym ../misc/web2a /usr/share/dict/words

dodoc ${D}/usr/share/misc/GNU-manifesto
rm ${D}/usr/share/misc/GNU-manifesto
}


The last line in my src_install() override seems heavy-handed.  I would have 
thought that dodoc would move the file into the doc directory from its default 
install location for me.

Can I avoid overriding src_install() entirely?  All I want to do here is move 
the GNU-manifesto file to the doc dir and create a /usr/share/dict/words 
symlink.

Bug in fontconfig postinstall script: spaces in *.ttf

[Warren Young]

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.

This error happens silently, but on the next run of setup.exe, you get a 
postinstall script error resulting from Cygwin’s refusal to chase an infinite 
link from Print.ttf to Print.ttf.  You also get a broken link to SketchFlow, 
but since it is not a tail-chaser, it doesn’t trigger the error.

The trivial fix for this is left as an exercise to the packager. :)

Incidentally, that font has a web page:

  http://www.marksimonson.com/notebook/view/sneak-preview-sketchflow-print

Kind of an interesting read.

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

[Warren Young]

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 the binary subpackages as x86*.

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

[Warren Young]

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 software, modify /etc/*, and so forth — 
nullifies its value.

But, if you do somehow lock down /etc/shells so that normal users can’t write 
to it, you’re also presumably locking down /bin, so a malicious user couldn’t 
drop in a bogus /bin/fish file and convince other software to run it as a shell.

Too bad there is no /etc/shells.d.  Then non-Base shells could just add 
themselves there.

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

[Warren Young]

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 maintained by
>> Yaakov are all at 2.1.0.  Some appear to have 2.1.1 alternate versions 
>> available
> 
> mingw64-*-expat were updated to 2.1.1 a few days ago already.

Might I ask how you even learned that a newer version was available?  The expat 
project doesn’t have mailing lists any more.  I was contacted by one of the 
upstream maintainers, which seems a bit back-channel to me.

I assume that someone who maintains so many packages has a better way to keep 
on top of which packages need to be updated.

Re: [ITP] procps-ng

[Warren Young]

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, that leaves us wanting a way in setup.hint to indicate that two 
packages conflict, else you can have the implementation ping-ponging between 
the two depending on which one is most recently updated, if you have both 
installed.

> $ tar xvf procps-ng-3.3.9-1.tar.xz
> …
> usr/bin/slabtop.exe

That should be left out.  It doesn’t do anything on Cygwin.

> usr/bin/tload.exe

That doesn’t seem to do anything.  I just get zeroes.

> usr/bin/w.exe

That’s not showing my login.  I’m not sure if it’s useful on Cygwin.

> usr/include/
> usr/include/proc/
> usr/include/proc/alloc.h
> usr/include/proc/devname.h
> usr/include/proc/escape.h
> usr/include/proc/procps.h
> usr/include/proc/pwcache.h
> usr/include/proc/readproc.h
> usr/include/proc/sig.h
> usr/include/proc/slab.h
> usr/include/proc/sysinfo.h
> usr/include/proc/version.h
> usr/include/proc/wchan.h
> usr/include/proc/whattime.h
> usr/lib/
> usr/lib/libprocps.a
> usr/lib/libprocps.dll.a
> usr/lib/pkgconfig/
> usr/lib/pkgconfig/libprocps.pc

All of this should be separated out into procps-ng-devel and libprocps-ng1 
packages.

See the attached expat.cygport file for an example.

> usr/sbin/sysctl.exe

What is that supposed to do on Cygwin, exactly?

All I know is that sysctl -a spammed my terminal. :)


Other than that, good job!  The only item above that is an absolute blocker for 
a GTG from me is the devel packaging stuff.




expat.cygport
Description: Binary data

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

[Warren Young]

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

[Warren Young]

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 with his/her
>> package.
> 
> s/scna/scan/ I suppose?

No, it’s a new Cygwin acronym entry: seriously consider not abdicating.

Re: [ITP] The Silver Searcher / Ag

[Warren Young]

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 to ag!)

Re: Changing Setup's license to GPLv3+

[Warren Young]

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 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 the DLL, not to setup.exe, so all
>> setup.exe contributors retained their copyright.
> 
> I'm not trying to do that single-handedly and without reason.  I'm
> asking here to reach out to the current active developers.  A switch
> from GPLv2+ to GPLv3+ works without having to reach out to *all*
> copyright holder.

I don’t think I agree with that.

Let’s say I write a standalone program and license it under GPLv2+ and give you 
a copy.  You can’t then relicense it under GPLv3 or GPLv3+ just because I said 
“or later” in the license.  *I* can relicense it, but only because I hold the 
original copyright.

All “or later” gives you the right to do is treat the code *as if* I had 
originally licensed it as v3, and then only if you want to.  This lets you link 
v2+ code to v3.  (But not v2-only code to v3!  More below.)

I think you’d still have to get permission from all people who still have code 
in the current setup.exe sources.

>> I can’t say I’m wild about GPLv3, for reasons which don’t have to be
>> rehashed here, being well-documented already:
> 
> GPLv3 is a nice license, IMHO.  I don't agree with Linus on that call.

It’s about a lot more than just Linus Torvalds and his personality quirks.

If you look at license stats, GPL is falling:

  http://www.softwarefreedom.org/resources/2013/lcs-slides-aaronw/#/rm-chart
  
https://blogs.the451group.com/opensource/2011/12/15/on-the-continuing-decline-of-the-gpl/

We’re seeing a big shift towards permissive licenses, and I think the GPLv3 
controversies have a lot to do with that.

>> What actual problem are you trying to solve with the change?
> 
> A certain mail to the cygwin ML might require some action.  The action
> is most thorougly (and quickly) done by pulling in some code from the
> Cygwin DLL.  But Cygwin is under v3+, so it's incompatible with the
> current v2+ in Setup.  That's why I'd like to bump version.

As I understand it (and IANAL) the GPL v2/v3 incompatibility only occurs with 
GPLv2-only licenses.  See the chart here, from the FSF:

  
https://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing

I suspect it is not kosher to intermix v2+ and v3+ code in the same file, but 
putting the v3+ code copied from the DLL into a separate file and calling out 
to it from the v2 code as if it were a library may be okay.

I could be wrong, in which case this is another argument against GPLv3.  The 
thing is viral even to past versions of itself.

FWIW, I’m no zealot.  I’ve got GPL’d and LGPL’d code out in the world.  I’m 
just pointing out that restrictive licenses (“free,” hah!) bring along a bag of 
problems.  GPLv3 adds a bunch more restrictions.

Re: Changing Setup's license to GPLv3+

[Warren Young]

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 the DLL, not to setup.exe, so all setup.exe contributors retained 
their copyright.

That’s what I was told by cgf back when I did my assignment prior to 
contributing some work to the tar handling, way back when Robert Collins was 
the lead on the project.  cgf said I didn’t need to go to that trouble after 
I’d already sent it in.

I can’t say I’m wild about GPLv3, for reasons which don’t have to be rehashed 
here, being well-documented already:

  
https://en.wikipedia.org/wiki/GNU_General_Public_License#GPLv3_separates_community_further

What actual problem are you trying to solve with the change?

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

[Warren Young]

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 irrelevant, since Cygwin doesn’t have that collision.

Also, not all of the pages mentioned have such a collision on Linux.  opendir 
and fnmatch, for two.

I don’t think Cygwin needs to replicate every Linux imperfection.  It’s okay if 
it manages to improve on some things, occasionally. :)

> I see nothing to fix in either package.

Would moving 3p in front of 3 be such a horrible change?

I mean, how often does someone want the gawk module pages anyway, as compared 
to the POSIX pages they shadow?

I expect 3 is in front of 3p for Linux because Linux has a separate set of 
non-POSIX pages.  But Cygwin doesn’t, and isn’t likely to, so 3p should be 
preferred.

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

[Warren Young]

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 
/etc/man_db.conf:

  SECTION 1 1p 8 2 3 3p 4 5 6 7 9 0p n

This causes “man readdir” to return the gawk page, not the POSIX page, as the 
user almost certainly intended.

To fix this, the man_db maintainer should add a 3am after 3p here, and the gawk 
maintainer should install the pages into the man3am directory.

Alternately, 3p could move in front of 3, since it’s more specific.  (You could 
say that man3p subclasses man3.)

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

[Warren Young]

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 MS Account instead of a local one, and its /var/log/setup.log 
*has* been touched recently.

setup.exe not logging on Windows 10 with MS accounts

[Warren Young]

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 should mimic the permissions 
setup.exe has while running under UAC, which is enabled on this box.

I later removed the setup.log files, and they weren’t re-created.

I thought the problem was that setup.exe doesn’t enable the logger when running 
elevated permissions (main.cc, line 290), but Achim Gratz dug deeper and says 
it should relaunch itself again and then enable the logger.

Achim Gratz noted that my default permissions may be weird because I am running 
with a Microsoft Account rather than a local one.

I have no particular need to run a MS account, I just took the default it 
pushed me into, since I upgraded this VM to Windows 10 to test Windows 10.  
Might as well use it with its defaults as much as possible, yes?  No point 
testing a new OS if I’m just going to turn off everything that’s new about it.




[1]: https://cygwin.com/ml/cygwin/2015-10/msg00179.html

Re: setup

[Warren Young]

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.

Sold. :)

Re: setup

[Warren Young]

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 a larger effort than adding a script here
 and there to an install system.

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?

Why do you need a self-contained POSIX environment to replace setup.exe?

Re: setup

[Warren Young]

 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 call it from 
Bash.  (In such a world, I hope it gets renamed to something less generic, like 
cygpkg.)  I was further assuming that setup-*.tar.xz would be packaged the same 
as any other Cygwin package, unpacking directly into /bin.

Thus, the MoveFileEx() call would be the one setup.exe normally offers, where 
it sees you’re trying to replace an in-use executable.

I was offering the background task alternative as a way around that.  However, 
the rest of your reply gives me a different idea.

 The idea is that setup is called, performs a CopyFile of itself
 and then exec's its copy.

If you mean that it always copies itself to some kind of temp space and execs 
it from there, that feels kind of wasteful, since you’re trading my design that 
copies only when required for one that copies every time.

But what if we invert it?  Why couldn't setup-*.tar.xz package unpack into 
/tmp?  The running setup.exe would exec it there with a flag that causes the 
second setup.exe instance to copy itself back into /bin.  Then there is only a 
copy made when setup.exe is actually being replaced, and /bin/setup.exe is kept 
up-to-date.

Re: setup

[Warren Young]

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 with a bare-bones setup.exe to bootstrap Cygwin, 
after which setup.exe would no longer be needed.

  https://github.com/transcode-open/apt-cyg
  https://cygwin.com/ml/cygwin-announce/2003-05/msg1.html

Then there was a pretty GUI installer someone made many years ago; I believe we 
were still in the 1.5.x line at the time.  I don’t remember enough about it to 
find it via Google again, but I do remember a few posts to the mailing list 
with positive responses.  Then the developer disappeared and no one took up the 
code base.

That’s part of what I mean about the difficulty of replacing key 
infrastructure.  Without either a change at the core or an overwhelming attack 
from outside, there just isn’t enough reason for someone to try to adopt 
something nonstandard.  Without that user base, there isn’t enough drive to 
continue development, so the project fizzles.

Consider the rise of Ubuntu-based Linuxes, replacing the various the RPM-based 
ones.  That didn’t happen purely because Ubuntu was “better.”  A necessary part 
of this was Shuttleworth pouring millions of dollars from a really lucky IPO 
into the project.

As proof, consider all of the Ubuntu clones that have gone nowhere, despite 
being “better” in some way.

The closest thing I can think of to success in the area you propose to tackle 
is mintty, which stepped into a gap between Windows Console and Cygwin/X + 
rxvt.  It didn’t try to replace either one, exactly, so it didn’t have to 
succeed by first making the other disappear.  “Better and separate” beats 
“better.”

Re: setup

[Warren Young]

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, setup.exe today has a lot of probably bitrotted features that
 Cygwin never used (even if some of it looks quite interesting and
 useful)

I don’t think there is any call for setup.exe to be highly 
backwards-compatible.  It isn’t asked to deal with old package repos, very old 
versions of setup.ini, etc.  Therefore, I would say that whoever is in charge 
of this code base should simply get rid of the bitrotted features.  

If any of these obsolete features are needed again in the future, they can be 
pulled out of the SCM history.

 there are other things it doesn't do even though it should
 probably be doing it.

Okay, but...

 Why do you need a self-contained POSIX environment to replace
 setup.exe?
 
 At the moment I'm just thinking whether that might be a more sustainable
 way forward.

Replacing core infrastructure like this almost never works out smoothly, and 
usually fails outright.  It’s far better to remediate the code base in-place, 
if at all possible.

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.

Re: setup

[Warren Young]

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.

But that’s a side issue, because I don’t see why you think you need Busybox in 
the first place, unless it is to be able to run postinst scripts.  Can’t you 
just say that that setup-*.tar.xz package never has a postinst script, so that 
all you need to do is un-tar it?

In that sense, setup.exe is already bootstrapped: it has everything within 
itself to be able to replace itself.

Re: setup

[Warren Young]

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 part of the Cygwin
 distro package set.  So setup updates itself, and it would be possible
 to handle public test releases.
 
 The issue of overwriting setup while setup is running could be worked
 around by setup first copying itself to a intermediate filename (e.g.
 .setup.exe) and then exce'ing that copy.

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.

This would be a nice point to give setup.exe a CLI language for installing 
packages in yum/apt-get fashion, too.  (Yes, yes, I know, SHTDI.)

Re: missing 64bit ports

[Warren Young]

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 and don't worry anynore.

Wow.  I’ve updated my related answer on Stack Overflow (http://goo.gl/yOAqAn) 
to reflect this drastic shrinkage of this list’s size.

Re: missing 64bit ports

[Warren Young]

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 list of allowed keys will be 
willing to accept a different key from you, so just resubmit it as if you were 
doing it for the first time.

Re: missing 64bit ports

[Warren Young]

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 running setup.exe.  The fact that some items are on that list 
because they’re orphaned and thus have no immediate prospect of getting off the 
list is inconsequential to the end users who consult it.

If your goal is to evaporate this list, I’d prefer that you just removed 
orphaned packages from both the 32- and 64-bit repositories on the 
justification that Cygwin should only offer packages available for both 
architectures.  And going forward, refuse new uploads if packages for both 
architectures aren’t provided promptly.

There can be exceptions, as with the recent libsigsegv thing.  I also thought I 
saw some talk about Perl currently being somewhat desynchronized at the moment. 
 I’m not talking about such cases.  The existing packages are maintained, and 
ownership of the solution for the missing packages is known.

I think this is going to far, but it would be well within your prerogative.

 - We should probably consider to remove the mingw.org packages.  All
  of them.  They are hopelessly outdated and mingw-w64 does the same
  job better hands down.

I can’t see why anyone would adopt those old abandoned packages.  Not only do I 
have no objection to you nuking them, I think it would be an actual 
improvement, since it removes a point of confusion in the setup.exe package 
selection screen.

Re: [HEADSUP] Dropping libopenssl098 from distro

[Warren Young]

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]

[Warren Young]

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?

Yes.

 (A single gold star is
 plenty for me; that plush hippo is above and beyond the level of effort
 it took :)

I dunno.  I see 5 major packages in that list.  5 ÷ π ≅ 1 hippo and two stars.

Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]

[Warren Young]

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 platinum, rhodium, 
and uranium stars now.

Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]

[Warren Young]

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?
 
 Hey, shall we move from goldstars to plush hippos?
 
 The standard solution is higher denominations.  So, we need platinum,
 rhodium, and uranium stars now.
 
 Hang on... plush hippos *are* a higher denomination.

What’s the exchange rate?

Re: [HEADSUP] Moving setup sources to git

[Warren Young]

 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

[Warren Young]

 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 shared Dropbox folder:

  https://cygwin.com/setup.html

Re: User manual cleanup

[Warren Young]

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 apparently quickly lost interested in working on the docs.

I rarely read the docs — shocking, I know — so I don’t get annoyed by their 
state.

So, when you find a section of the docs that sucks, and you can’t be bothered 
to fix it at the moment, ping me.

 screen
 SYSTEM S-1-5-18= uid/gid: 18
 Users  S-1-5-32-545= uid/gid: 545
 /screen

I think you might want informaltable here:

 http://docbook.org/tdg/en/html/informaltable.html

If the results don’t look good to you, it probably only requires some CSS to 
fix it.

That’s a common trap with DocBook: trying something and not liking the initial 
rendered result, and dismissing it right there without trying to customize it 
first.

Re: [HEADSUP] Base category

[Warren Young]

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?  Cygwin has just a few thousand
 packages, Linux distros have 10s of thousands.

I just re-did the count, and I get 4,453 for the Cygwin official repo (x86) 
plus another 6,556 in Ports.

My point, though, is that I’m surprised Cygwin is even in this space.  Back 
when I started with Cygwin, it was little more than a POSIX.1 userland.

I understand “nonstandard” additions like ssh, rsync, a basic X server, lots of 
libraries, and lots of development tools.  What I don’t understand is 
WindowMaker, KDE, music notation software, etc.  It seems to me that a lot of 
this is best left to Windows proper, or native apps for it.

Of course I don’t need to understand it.  It’s someone’s itch, and it pleases 
them to help Cygwin out by scratching it.

 I only have VMs now.  I’ll probably be fading
 from the Cygwin scene as a consequence.
 
 Oh well.  I'm running Windows in VMs only for years and I still didn't
 disappear from the project :}

It’s a bit different for you, isn’t it?  For you, it’s a key part of your 
employment.  For me, it’s been a means to an end, while I waited for the 
computing world to change enough that I could get off Windows.

It’s not that I don’t want to continue helping with Cygwin, but that it’s no 
longer a thing I use often.

 I'm sorry to read that.  In fact I had hoped you would be willing to
 look a bit more into the documentation again, after you so kindly pulled
 it into the 21st century last year.  There's certainly still much room
 for improvement.

I kind of thought I’d been kicked off that project, after leaving the autodep 
stuff hanging. :)

Point me at a problem area.  If it annoys me enough, I will be motivated to fix 
it.

As for your new nsswitch type docs, the first pass still needs to be done by 
you, or whoever knows what’s going on.  But, I can still make a cleanup pass on 
it.

Re: [HEADSUP] Base category

[Warren Young]

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 on keeping the base install
 so very small.  Our Base package set is really tiny in comparison
 with any Linux distro.  Perl is default on most of them.  Why not
 for us?  Disk space is dirt cheap these days.

I agree with both sides of the argument.  A tightly-scoped minimal install is a 
good thing, and it would be a good thing if we could have a 
universally-available programming language that fills the vast gap between sh 
and C. [1]

While I lean toward your side, that’s only because I’ve been a Perl programmer 
for about 2 decades.  If I look at it impartially, I can’t say that Perl really 
should get a special place short of being formally included in POSIX or 
similar.  Otherwise, why not include Python, Ruby, Lua, Scheme…? 

It can't just be because it’s older; Scheme’s got Perl beat by a dozen years.  
It’s older than Awk!

I think in the end, I look at Cygwin as more similar to a minimal 
server-focussed *ix than to a desktop *ix.

I believe this difference stems from the fact that Windows is a pretty capable 
desktop environment in its own right.  Obviously far from ideal, but I think 
most of those of us who use Cygwin are more interested in filling in gaps in 
Windows than in replacing it.

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]

It is possible to install so much within Cygwin that you turn Windows into a 
rather slow Linux distro with a demented kernel.  If you’re going to do that, 
why not just switch to Linux or OS X on the desktop, and run *Windows* in a VM?

This is as good a time as any to tell anyone who cares that I’ve finally done 
just that: I recently retired my last machine that boots natively into Windows. 
 I only have VMs now.  I’ll probably be fading from the Cygwin scene as a 
consequence.  I expect it to be a slow fade, since I still feel the need to pay 
back some of the value Cygwin provided to me in the years before we got mature 
VM systems.

Therefore: So long, and can I help you find some fish before I go? :)


[1] This is what sparked my post to the -talk list, if it’s not clear by now.

[2] 90% of everything is crap, but we disagree on which 90% that is.

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

[Warren Young]

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 them dependencies of both libapr*-devel and 
apache2.

Re: Package categorization inconsistencies

[Warren Young]

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

[Warren Young]

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, gtk-doc,
ImageMagick-doc, libcaca-doc, libcloog-isl-doc, libdatrie-doc,
libgmp-doc, libgstreamer1.0-doc, libisl-doc, liblapack-doc,
libmpc-doc, libmpfr-doc, libpoco-doc, libsigc2.0-doc, libthai-doc,
libunistring-doc, libxcb-doc, libxml2-doc, libxslt-doc, libxslt2-doc,
llvm-doc, octave-doc, postgresql-doc, ppl-doc, qt4-doc, ruby-doc,
texlive-collection-*-doc, tiff-doc: Not in Doc category

The Doc category seems to have two different purposes: documentation, 
and tools to create documentation.  Currently, there are far more of the 
former in this category.  Should there be a new category for the tools? 
 (e.g. gnome-doc-utils, man, manlint, pinfo, xmlto...)


glproto, presentproto, xextproto, xproto: In Devel category, but not X11 
category, yet they are part of X11.  And, vice versa: the other *proto 
packages that are in X11 probably should be in Devel, too.



[*] http://goo.gl/lu61sZ

Re: [ITA] tcl-sqlite3

[Warren Young]

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 sqlite 3.x.x version, IMHO.


Yaakov makes a good point: the whole idea of tcl-sqlite is that it wraps 
the SQLite 3 API exactly, so when new public APIs get exported by 
SQLite, new APIs appear in the Tcl wrapper.  Therefore, a new version of 
tcl-sqlite really *could* depend on a specific version of SQLite, if the 
API changed.

Re: [ITA] tcl-sqlite3

[Warren Young]

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 should seek a GTG.

A second pair of eyeballs can't hurt.


otherwise Warren Young would be the most logical choice.


Not really.  I've never used tcl-sqlite, and I haven't used Tcl in at 
least a dozen years.

Re: [ITA] sqlite3

[Warren Young]

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.  What I saw of the tarball contents looked 
good, but I didn't actually install and exercise packages here.


Jan, will you please put the package tarballs you intend to upload on a 
public file server somewhere?  You can send the link directly to me, or 
post it in reply to this thread.  I'll want to test both 32- and 64-bit 
versions.


Don't worry about the tclsqlite package at this point.  There's no 
reason that should hold up the main packages.

Re: [ITA] sqlite3

[Warren Young]

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, and -devel), 
examining the file list, running the exe, and running svn to make sure 
it loaded the DLL correctly.  I had to rebase on 32-bit, but that's 
probably not surprising since I did a manual install.


Jan, some nits to take care of in the next sqlite3.README file:

- It still mentions lemon3.exe.

- I wasn't the maintainer of all prior versions of Cygwin SQLite.  I 
started with 3.5.8.  I don't remember who the prior maintainer of the 
official Cygwin SQLite package was.  From the port notes, I started from 
Yaakov's Cygwin Ports version, but it was someone else's package I was 
replacing in the official distro.


- Typo: idential - identical

Also, when you post your cygwin-announce message, be sure to describe 
the new VFS switching mechanism.  One of the READMEs should describe 
this Cygwin-specific environment variable in some detail, too.

Re: [ITA] sqlite3

[Warren Young]

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 the driving force behind fixing the problems that prevented 
a simple update from SQLite 3.7.x to 3.8 on Cygwin.  (3.8 is a big 
upstream release, and they broke a lot of things on Cygwin, since it 
isn't a primary deployment platform for them.)


The only reason I adopted this package in the first place is that the 
previous maintainer disappeared, and it was about to be removed from the 
distribution.  I just stepped in to rescue it.  I have never actually 
*used* SQLite on Cygwin, other than testing; Cygwin SQLite has never 
been my itch.


I expect Jan to be a better SQLite package adoptive parent than I was.

Via private email and on the SQLite list, I've been explaining the whys 
and wherefores of the current Cygwin SQLite package to Jan and others. 
I don't intend to disappear entirely from the SQLite world, but I think 
most of the knowledge transfer has already happened.

SSH key for upload access

[Warren Young]

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

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

[Warren Young]

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.  A 
complete re-checkout and re-build fixed it.  shrug

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

[Warren Young]

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 narrowed the problem down to a difference in the generated 
.libs/libsqlite3.lai file.


With the SQLite source repo tip, that file contains:

dlname='cygsqlite3-0.dll'

In 3.7.17, the same line is this instead:

dlname='../bin/cygsqlite3-0.dll'

One of the many differences between SQLite 3.7 and 3.8 is that 3.7 
shipped a libtool based on libtool 1.5, whereas the 3.8 source tree 
currently includes ltmain.sh 2.2.6 from libtool 2.4.  That's the current 
version on Cygwin, too, so re-running libtoolize or autoreconf doesn't help.


Did this feature change its nature between libtool 1.x and 2.x?

Another difference is that SQLite is no longer using automake.  Perhaps 
the Makefile.in generated from SQLite 3.7's Makefile.am was doing 
something that the handwritten Makefile.in in SQLite 3.8.1 doesn't?


If you want to see this yourself:

$ cd some/tmp/dir
$ fossil clone http://www.sqlite.org/cgi/src sqlite3.fossil
$ mkdir sqlite3-head
$ cd sqlite3-head
$ fossil open ../sqlite3.fossil
$ ./configure
$ make libsqlite3.la
$ ./libtool --mode=install install libsqlite3.la /usr/local/lib

(The latter two steps are a simplified form of make install without a 
lot of unrelated junk getting in the way of seeing the problem.)


Obviously, I can hack around this in my cygport file, but I'm hoping 
there's a way we can fix the SQLite build system so that it does the 
right thing without a post facto hack.

Re: libevent-2.0.21

[Warren Young]

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 it.


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, too.  That is, 
if libevent needs some fix or update to allow those packages to continue 
working, you'll be pressured to fix it even though you do not need the 
fix yourself for tmux.

Re: libevent-2.0.21

[Warren Young]

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, that would that only apply if other packages dependent on
libevent are brought into Cygwin in the future, yes?


No.  If you were to adopt libevent, Yaakov would be able to remove it 
from Cygwin Ports, because those packages could then use the official 
libevent pacakge.  (i.e. yours.)

Re: questions on using cygport, first steps

[Warren Young]

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 correct starting point is:

$ cygport Singular-4-0-0.cygport all

The 'all' command runs download, prep, compile, install, package, and 
finish, in that order.  (Maybe test, too.)  You will fail at 'download' 
if SRC_URI isn't set correctly.


It's not terribly coherent with regard to your perspective, but this 
answer I wrote on SO should at least get you oriented a bit better:


http://stackoverflow.com/questions/11619415/#11678875

Re: sqlite3

[Warren Young]

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 dislike chasing threads across lists, I'll reply here.


SQLite header and source version mismatch
2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668
2013-04-12 11:52:43 cbea02d93865ce0e06789db95fd9168ebac970c7


Please post your cygcheck output per http://cygwin.com/problems.html to 
the main list.


Also, what does 'type -a sqlite3' say?

Feel free to start a new thread on the main list with the answers.


it seems like one would expect it to work as packaged.


Well, seeing as how this the the first such complaint I've received 
about SQLite3 3.7.17-3, which has been the current version for over 2 
months now, I'd say it probably does work as packaged.


Something is odd about your particular machine.  The cygcheck output 
should help us figure out what that peculiarity is.

[RFU] expat-2.1.0-3

[Warren Young]

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 -A'*2.1.0-3*' -A'*.hint' \
 -r http://etr-usa.com/cygwin/x86/expat/


From within x86_64/release/expat:

wget -e robots=off --cut-dirs=3 -np -nH -A'*2.1.0-3*' -A'*.hint' \
 -r http://etr-usa.com/cygwin/x86_64/expat/

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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-ports.git.sourceforge.net/cygwin-ports/cygport
 Cloning into 'cygport'...
 fatal: The remote end hung up unexpectedly

What am I missing?

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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
automatically get new packages on their next Cygwin update.


If you're willing to do that for 32 and 64 bit, ok.


...aren't I going to get exactly the same output tarballs as
before, just with different names?


The content of the src packages won't match the new version if we
just copy the files.  A rebuild is simplest and cleanest.


Okay.

I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a 
guinea pig for it.

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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: cygwin libexpat1
external-source: expat
sdesc: Expat XML parser library (development)
ldesc: This is Expat, a C library for parsing XML, written by James
Clark. Expat is a stream-oriented XML parser.  This means that you
register handlers with the parser before starting the parse.  These
handlers are called when the parser discovers the associated structures
in the document being parsed.  A start tag is an example of the kind of
structures for which you may register handlers.

Doesn't the first line do what you want?

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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 to 
re-pull them.

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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 it waiting on me.  I've run out of time to do Cygwin 
packaging today, and may not have time again until next week.

[RFU 64-bit] sqlite3-3.7.17-3

[Warren Young]

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 to promote the test 
packages to curr.)

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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
HOMEPAGE=http://expat.sourceforge.net/;
SRC_URI=mirror://sourceforge/${PN}/${P}.tar.gz

abi=1
PKG_NAMES=${PN} lib${PN}${abi} lib${PN}-devel
PKG_HINTS=setup lib${abi} devel
PKG_CONTENTS[0]='usr/bin/*.exe usr/share/'
PKG_CONTENTS[1]=usr/bin/*-${abi}.dll
PKG_CONTENTS[2]='usr/include/ usr/lib/'

CYGCONF_ARGS=--enable-static

DIFF_EXCLUDES=expat_config.h.in

HTMLDOCS=doc/*.png doc/*.html doc/*.css



The only change from the one I used to build the -2 package is that the 
PKG_NAMES line used to be:


PKG_NAMES=${PN} lib${PN}${abi} lib${PN}${abi}-devel



It's probably best to just rename this stuff in the repo.  The last 
release of Expat was 6 years ago, and I have no information that leads 
me to expect another release soon.  If there were an imminent release 
due, I'd say hold off, and let me roll the change into that version.


Anyway, I've changed my local .cygport file as above, in case I ever 
have to use it again. :)

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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 problem fix itself for those using Cygport's .hint file 
generation?  For those not using this feature, it would be a gentle clue 
why it's a good idea.


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.

Re: [RFC] cygport: PKG_OBSOLETES

[Warren Young]

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 that for 32 and 64 bit, ok.


I don't see what you need from me.  Can't you just copy *-2* to *-3* 
except for libexpat1-devel*-2* which becomes libexpat-devel*-3*, then 
manually change all the *.hint files referencing libexpat1-devel?


I mean, if I rebuild my packages here using the new .cygport file I 
posted, aren't I going to get exactly the same output tarballs as 
before, just with different names?

Re: sqlite defect

[Warren Young]

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 fix it if you are trying to use two or 
more Cygwin SQLite based programs to access a single database file.


The default mode for Cygwin SQLite is now -- and pretty much always has 
been -- to prefer allowing a single Cygwin SQLite program to cooperate 
with any number of native Windows programs for access to a single SQLite 
DB file.


This means that in this posix mode, Cygwin SQLite is no longer likely 
to cooperate with native Windows SQLite based programs for access to a 
shared DB file.  That's the tradeoff: choose to share with other Cygwin 
programs, or choose to share with native Windows programs.



I remember there was a discussion
on the cygwin general mailing list about this problem
(backslashes in path?).


If that's what's going on, my .17-3 build should have fixed the problem, 
not manifested it.

Re: sqlite defect

[Warren Young]

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

[Warren Young]

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 it a while.  Just in this past week, I got a complaint 
about one of the changes in .16.2 relative to .13, so it's conceivable 
some may want to step back two steps if .17 doesn't work out for everyone.

Re: [RFC] cygport documentation

[Warren Young]

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
accordingly.


Agreed.  The current HTML manual -- awesome as it is compared to the old 
README file -- relies on you know know what you're looking for already. 
 The biggest holes remaining are the missing answers for questions of 
the form, How do I get Cygport to do X for me?


It might also help to walk through several real cygport files:

1. A very basic one, such as one for an autotools based project that 
requires no patching and no special configuration.


2. A more complicated one showing how to do common things.  You're in a 
much better position than me to define common, Yaakov, so I won't try.


3. One for a package with a seriously oddball build system, requiring 
that you override a lot of what cygport tries to do for you by default.

Re: [RFU] sqlite3-3.7.17-3

[Warren Young]

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

[Warren Young]

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 manually adjust the generated .hint files on test 
releases on my end.

[RFU] sqlite3-3.7.17-3

[Warren Young]

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 tarballs.)


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/cygwin/sqlite3/

Re: [RFC] vim-minimal in Base?

[Warren Young]

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 the days when I forget to install an editor 
on a new Cygwin install, then have to go re-run setup to fix that.


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.

Re: [RFC] vim-minimal in Base?

[Warren Young]

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

[Warren Young]

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 feature to do this already?

Re: cygport-0.12.0-1: too many arguments

[Warren Young]

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

$ head -c 2 xfig-VERSION-REV/inst/usr/bin/xfig.exe | hexdump

?

Yaakov, recasting the test like this might fix it:

if od -t x2 -N2 ${exe} | grep -q '000 2123'
then
   ...

Re: HELP with Cygwin docs needed

[Warren Young]

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 XIncludes if you go with DBX.


Yes, I'm kinda sorta volunteering, and am asking if there is a reason I 
shouldn't bother. :)

Re: HELP with Cygwin docs needed

[Warren Young]

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, I suspect the 
conversion was already made, and the files just didn't get renamed to 
reflect their new format.  Perhaps that's because Cygwin is still hosted 
in CVS, so that a rename would break revision history.


Anyway, the advantage that prompted my question is that if you hadn't 
figured the problem out on your own, I think you would have gotten more 
help replies, faster, if you'd asked if anyone knew DocBook and xmlto 
instead of SGML and xmlto.  SGML DocBook is essentially a legacy 
document format now, used by those who can't or won't convert.


(I base that judgement on being a DocBook user for nearly a decade, and 
following the DocBook mailing list the whole time.  DocBook SGML was 
already on its way out when I got started, so I never even bothered 
going down that path.)


Other advantages of the XML dialect over the SGML dialect:

- SGML predates Unicode, so the tools typically don't support it.  XML 
was designed with Unicode in mind from the start.  Umlauts without 
hackery! :)


- The DocBook XSL stylesheets maintained by Norman Walsh are kept more 
up to date with the current DocBook dialect.  In fact, it's looking like 
DocBook 5 will never be available in an SGML dialect.


- The DocBook 4 and earlier specs were written so that the XML and SGML 
dialects are supposed to be treated identically by tools consuming them, 
but that guarantee has no substance without two equivalent sets of 
stylesheets.  Because the SGML stylesheets aren't kept up to date, the 
compatibility guarantee from the spec is toothless, unless you're 
willing to maintain your own set of stylesheets.


- The tools to process XML, XSL, XSLT, and XML-FO are also all kept in 
better shape than the old SGML based tools.


- Having never used the SGML dialect of DocBook, I do not know for 
certain, but I suspect it's easier to hack DocBook XML.  E.g. Via local 
XSLT stylesheet overrides.


- I think you could avoid the need for all that amp; and lt; hackery 
in your C code snippets in the docs if you used XML's CDATA feature.



   I write the docs in vi.


Me, too. :)


   don't want to use some GUI editor


Sadly, the GUI tools for DocBook XML really aren't where they ought to 
be, even if you wanted to use them.


For example, there *should* be a basic DocBook based word processor 
along the lines of LyX, but there isn't.


Instead, those wanting a simplified WYSYWYG presentation have to deal 
with monstrous XML powerhouses like oXygen.  And even then, WYSIWYG 
isn't the right term for for the experience.  It's more like the bad old 
days of web development where no two browsers gave the same result for a 
given bit of markup.



   I wouldn't want to have relearning how to write the
   docs, unless there's a definitive advantage here.


The XML and SGML dialects of DocBook really aren't that different, in 
the main.  You still have your sect1 and para type stuff.  Where 
they differ is in the toolchain and the customization layers.


And as I now see, it looks like most of this work has been done already. 
 It looks like the main things remaining would be to rename *.sgml to 
*.xml and *.dsl to *.xsl to reflect their actual current contents, wrap 
the SGML fragment documents in proper XML containers, and then 
probably switch from the nonstandard doctool to XIncludes.


I suspect that if I did that, you won't immediately see a difference, 
except that all .sgml became .xml.



- Will it work equally well to build the docs on Cygwin and on Fedora?
   Are the tools part of a default distro in both environments?


The GNOME docs are split between DocBook XML and SGML[1].  So, yes, you 
can generally count on having the DocBook XML tools installed on Red 
Hattish Linuxes.  And if not, say because you've got a minimalist 
install, the tools are in the stock repos.


As for Cygwin, I've built my two DBX manuals under Cygwin before, just 
to prove it can be done.  I tend to build on Linux and OS X for normal 
development, however, so it's been a while since I've tried this.


[1] https://en.wikipedia.org/wiki/Xinclude
[2] http://goo.gl/jDmuw

Re: HELP with Cygwin docs needed

[Warren Young]

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

[Warren Young]

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 xsltproc is in the 
Cygwin package repo.  Since xmlto depends on it, you should have it on 
your system already.  xmlto does seem to have enabled the feature.  (vi 
+218 `which xmlto`)


Obviously I'll know more once I attempt the conversion.

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

[Warren Young]

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 
feature, specifically its ability to build the requires line automatically.


I moved to this new feature for this package release, but I copied over 
the requirements from my hand-written hint files.  I just removed the 
REQUIRES lines and verified that Cygport does the right thing here.


The automatic dependency generation doesn't include ncurses explicitly, 
but it does include readline which depends on ncurses.  I expect 
setup.exe will follow the dependency chain correctly.

[RFU 64bit] sqlite3-3.7.16.2-1

[Warren Young]

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

[Warren Young]

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 packages, and leave 2.0.1 as -prev.

While in the release/expat directory:

wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \
http://etr-usa.com/cygwin/expat/

[RFU 64bit] expat-2.1.0-2

[Warren Young]

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 directory:

wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \
http://etr-usa.com/cygwin64/expat/

[RFU 64bit] ctags-5.8-1

[Warren Young]

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

[Warren Young]

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

[Warren Young]

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 just felt the 
tickle of an overly broad brush.  But, you asked for comments, you got 
more discussion than you wanted, so you stomped off saying you wish 
you'd never asked.  Makes one wary of answering your RFCs.  Makes one 
think you'd rather just be BDFL and not ask any more.  Just sayin'.)



1) Do you have a 64-bit version of Windows available?


Yes.


3) Are you willing to download the current 64-bit Cygwin and start porting
your stuff, knowing that there are still bugs?


Sure.  It's a question of round-tuit for me, not a worry over bugs.

As far as I'm concerned, for the first several months, the 64-bit 
version can be buggy as hell and still be worthwhile.  For now, I'm 
happy enough that it *exists*.  Stability can come over time.



5) Does the existence of two different architectures make you think that
it is time for you to stop offering the package?


I'd be happier not having to rebuild everything twice, but I don't see a 
way around that given Windows' approach to CPU compatibility.


(Compare OS X, where a single binary can contain code for multiple CPU 
types.  The program still does get compiled separately for each target, 
but the tools all handle this detail for you.  You only notice it in 
that the compile time goes up by a factor of $ncpus.)



6) Would you be willing to have another person doing the 64-bit port for
you?


Sure, if someone wants to.  If it gets done, I'm not going to squawk 
about *who* got it done.


If that happens and they post their patches, I might then take them and 
start releasing both versions.



7) Are you ok with a 64-bit alpha release being made available which contains
your packages built by someone else?


If that's how it has to go, sure.

But to me, alpha means not yet feature complete in addition to has 
known bugs.  I wouldn't even make repo completeness a prerequisite for 
getting 64-bit Cygwin out of beta.  A certain core set of packages must 
be present from the start for the release to be of use, but a great many 
more can trickle in over time.


I don't see that my set (ctags, sqlite, expat) are so critical that they 
belong in that must-have set.  All nice and useful to be sure, but not 
exactly Base packages.  Two of mine are libraries, so I can see getting 
pressure from *other maintainers* to build 64-bit versions so they can 
proceed with their builds, where my package's library is a requirement 
for their package.  That's the level where pressure to release 64-bit 
builds should happen for most packages, rather than from the top.


As for packages that aren't dependencies of anything else, pressure 
should come from the user base.  If no one cares enough about a given 
missing 64-bit package to complain about it, it shouldn't be a 
priority for that maintainer to build it.

Re: nuke cygwin legacy?

[Warren Young]

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 probably won't be watching this list, or to 
the cygwin.com home page.


I propose making the deprecation a two-stage affair:

1. Move Cygwin 1.5 somewhere else, so that it doesn't get included in 
mirrors.


2. Point everything referring to the old mirror system at the new 
location, presumably a different subtree on sourceware.org.  Then you 
can rely on the FTP/HTTP logs to determine how often people actually 
install these packages.


There's a core assumption here, which is that download volumes have 
dropped enough that going back to a single download server is sane.  If 
it turns out that download volume is unexpectedly high, though, well, 
that's answer enough, isn't it?

Re: sqlite3-3.7.15-1 test packages

[Warren Young]

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 for testing:

  http://etr-usa.com/cygwin/sqlite3/libsqlite3-devel-3.7.15.1-1.tar.bz2
  http://etr-usa.com/cygwin/sqlite3/libsqlite3_0-3.7.15.1-1.tar.bz2
  http://etr-usa.com/cygwin/sqlite3/sqlite3-3.7.15.1-1-src.tar.bz2
  http://etr-usa.com/cygwin/sqlite3/sqlite3-3.7.15.1-1.tar.bz2

These packages enable the requested build options.

*Plus*, they attempt to work around at least one of the problems that 
lead us to try building SQLite in Unix mode on Cygwin in the first 
place.  Instead of a wholesale Unix mode switch, we only do temporary 
directory selection in a Unix way instead of asking Windows for a 
temporary directory, which is often not user-writeable when the user is 
not an admin.  This certainly tries to address Daniel Colascione's 
reported problem, and may address Achim Gratz' original problem, too.


This required a fairly ugly hack to the SQLite code, so I'm not even 
going to consider posting an RFU message for these packages until I get 
some positive feedback from those affected.

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

[Warren Young]

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 will find the other duplicates:


grep -o '/[a-z0-9]+\.exe$' filelist | sort | uniq -d

Some will be harmless, like the two ksh.exe versions.  But, maybe 
something interesting will turn up.



Volker, would you mind a lot to obsolete the xemacs-tags package
in favor of the ctags package?


As long as Exuberant Ctags is a complete superset of the functionality 
in xemacs-tags, this seems like a good idea.  Anything that depends on 
xemacs-tags can depend on the ctags package instead.

Re: HEADSUP: lesstif replaced by motif

[Warren Young]

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 PROBLEMS file with solutions don't use a UTF-8
locale or link with lesstif :-)


Isn't the core problem that DDD has been semi-maintainerless[*] for 
years, and that these are the same as the years of UTF-8's ascendancy?


I ask because it's the basis of my guess is that if you tried to provide 
a patch upstream, it would be ignored.  That, or they'd invite you to 
become the new maintainer. :)


So, my advice is to either maintain a private patch for Cygwin DDD or 
take over maintainership of DDD.



[*] https://www.gnu.org/software/ddd/news.html


A minimal fix might be to just replace the
ISO-8859-1 encoded strings with their ASCII equivalents (e.g. ü - u)


German umlaut-ed characters are generally Anglicized as ue, oe, etc.


a better solution might
be to actually fix ddd, but I have no idea what would be involved.


The easiest way to fix this is with iconv(1):

$ iconv -f iso-8859-1 -t utf-8  foo.c  foo-fixed.c
$ wc -c foo.c foo-fixed.c
N foo.c
N+M foo-fixed.c
$ mv foo-fixed.c foo.c

N is the original file size and M will be at least 1 byte per replaced 
character, but potentially up to 3 per replaced character.


I suspect you'll run into a problem if you're using cygport.  It will 
try to make a patch file for you when it sees that you've run iconv on 
the -src directory contents, since the corresponding -origsrc files are 
now different.  But, since cygport is running in a UTF-8 locale, it's 
going to either truncate the 8859 input files or mangle them.  You might 
have to do some shell script gymnastics to avoid this.


All the more reason to arm-twist upstream, if you can.  Or become 
upstream. :)

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

[Warren Young]

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 happy.



FSF recommends use of existing licences (GNU licences, Apache
...), likewise OSI:

 We recommend that you always apply an approved Open Source license to
 software you are releasing, rather than try to
 waive copyright [= put into public domain] altogether.
 http://opensource.org/faq#public-domain


CC0 is a bit more complicated than pure public domain.


 ... This “Give-It-Away” license provides no protection for anyone
 if the donated software causes harm (...) one [cannot] escape a
 lawsuit just because his gift was only accidentally harmful.


CC0 contains a warranty disclaimer.  (§4.b.)


If utmost free were the initial intention -- What was wrong with the
BSD[1] or MIT licenses, which are desinged to be Open Source software
licenses?


My point is that this is basically what you get, when you live somewhere 
that doesn't allow public domain copyright disclaimer.

Re: LICENSE: base-files and use of CC0

[Warren Young]

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 for code snippets that accompany documentation (e.g.
code presented in manual).


According to the OSI FAQ item you pointed to, the problem is that the 
CC0 license doesn't stay mum on the subject of patent and trademark 
release, and it doesn't fork over all rights to relevant PT's.  Other 
than that, what you have is basically BSD 3-clause in the worst case, 
where the local laws don't allow public domain.


How is this a problem again?  Are there patents and trademarks owned by 
these contributors that we think we will want to use in the future?

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

[Warren Young]

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:, curr: and such be necessary if the next version 
comes out with the same numbering scheme?

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

[Warren Young]

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 sourceware.org (?) and just monitor the list for RFU 
messages and handle them all automatically?



If the email contains a string like:

Please remove 5.42-1 then that package will be removed and temporarily
archived to a tar file in /tmp.


Every natural language processor I've used -- including very well funded 
ones like Siri -- require that the human conform to the limitations of 
the computer's natural language parser.  They give the illusion of 
flexibility while they generate frustration by refusing to accept text 
that looks similar to forms it does support.


I think it's great that you've gone and done this, Chris.  You can 
expect people to keep posting RFUs by the copy-paste-edit-send method, 
and the current forms are well understood.


My point is that if you ever find yourself wanting to extend the natural 
language parser to cover another new case, instead of spending that time 
writing more natural language parsing code or a nastygram to the person 
who wrote the RFU, stop and consider.  It might be better to spend that 
time inventing a more robust RFU message format that a script can parse 
with 100% confidence: if it parses, it's legal.


For example, you can repurpose your setup.ini parser:

[cygrfu]
root: http://etr-usa.com/cygwin/
packages: ctags
version: 5.8-2

That, coupled with info parsed from the package's existing setup.hint 
files or the setup.ini file would tell the script everything it needs to 
know to do the right thing.  This formal RFU is saying that the script 
should expect a sourceware.org like release tree at the root path given, 
and that the package names found there differ only in the version number.


The packages: line allows for single logical packages that are 
actually composed of several separate packages:


packages: sqlite3, libsqlite3_0, libsqlite3-devel

This is where parsing setup.ini comes in: it looks for [libsqlite3_0] to 
learn that it should expect to find it in sqlite3/libsqlite3_0 under 
the given root, not in sqlite3.


The formal RFU request doesn't mention -src and -debuginfo because the 
tool already has the information to handle them implicitly.


Then you can add tags for exceptional conditions:

[cygrfu]

prev: 5.7-1

That would mean remove 5.8-1 and leave the earlier 5.7-1 as prev. 
That as opposed to its default action, which would be to remove 5.7-1 
and leave 5.8-1 as prev.


The point of all this would be to get to a point where the script can 
monitor the mailing list and be expected to DTRT 100% of the time.


The incentive to you, Chris, is that it potentially gets the human out 
of the RFU loop entirely.  This should defeat the SHTDI argument, too. 
The Someone is one of those with upload privileges who wants a computer 
to put them out of a job. :)


The incentive to the package maintainers is that if they use this 
format, they know the script will pick up their packages in computer 
time, instead of waiting for a human to process an informal RFU.  A 
package maintainer might therefore have some hope of getting a fix out 
to the mirrors within 24 hours of sending the RFU.


You might consider whether to add an email whitelist to this, which 
controls whether the script will pay attention to formal RFUs.  Newbie 
maintainers or those the uploaders don't entirely trust for whatever 
reason won't be on the list.


I think that's probably a sign they shouldn't have maintainership at 
all, though.  The more independence you give the package maintainers, 
the fewer synchronization points you have, which is good for speed, as 
any experienced computer programmer knows.


That said, a whitelist containing all package maintainers' known emails 
is probably still a good thing.  You wouldn't want the script accepting 
formal RFU requests from random people.

Re: upload protocol

[Warren Young]

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 
RFU'd the result.  There was pretty much no way you could have lost the 
GTG status.


But whatever, it all came out okay.

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.

[Warren Young]

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 a similar 
discussion over a proposed package upload, but even if my recollection 
is correct, I think the public document takes precedence.



2. /usr/share/doc/doxygen/latex should be removed,


I agree completely, but I kept the 'latex' directory for a couple of
reasons. Firstly, this was consistent with the previous build of doxygen
(1.7.4-1), which included the latex directory [1].


Yes, I realize you were just following my previous example, but I'm far 
from infallible.  I saw something in your package I would have removed 
from mine if I'd realized that at the time.



Secondly, I rather
thought that if 'make install' wanted to install the latex directory
then it wasn't really my place to delete of it.


That's a much stronger argument.

You might ask on the Doxygen mailing list why they think Joe User wants 
the LaTeX manual sources installed.  It might be something they've 
overlooked in their build system.



However, I've had a little look at a couple of popular Linux
distributions, and neither Fedora [2] nor Ubuntu [3] include the latex
directory in their doxygen packages.


Ditto RHEL.


There's a bogus test in Doxygen's configure script, where it goes
looking for dot(1) from GraphViz.  It does a weak check for it in a
few common locations, and yells if it isn't there.  dot(1) being a
filter, there isn't a huge penalty for using the native Windows
version, which of course doesn't get installed in any of those
locations.  It would be nice to either 1) send upstream a test using
the PATH instead of a hardcoded list; or 2) adopt Yaakov's GraphViz
package:


If the configure script doesn't detect dot(1) then it isn't the end of
the world - you can specify the location of the dot executable by
specifying DOT_PATH in the project configuration file:


Are you sure Doxygen doesn't use dot during the package build process, 
such as part of building Doxygen's own manual?  I don't see why it would 
bother trying to find it at configure time otherwise.

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.

[Warren Young]

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 -1 for subsequent build attempts until one gets 
RFU'd.  Use new package versions only to disambiguate published package 
versions.  The package version number is there to help setup.exe out, 
not to help us poor humans out. :)


Nits:

1. Another build requirement change: the doxygen.README file still 
refers to TeTeX, which was replaced recently with TeX Live.  But, 
installing a basic TeX setup alone isn't enough.  To build the PDF 
manual, you need the optional texlive-collection-fontutils package for 
epstopdf, and texlive-collection-latexextra for float.sty.  There's no 
need to mention any other packages.  Installing those two into a stock 
Cygwin install will drag in enough of the remaining TeX stuff to build 
the manual.


2. /usr/share/doc/doxygen/latex should be removed, in favor of a .../pdf 
subdirectory.  I don't see a reason to ship source and intermediate 
build files here, expecting the user to build the docs.  What's wanted 
here is a PDF of the LaTeX *output*.


3. I'd rather see your first version be 1.8.2-1 instead.  Why start with 
a version two bug fix releases back?


Nits aside, I can't withhold a GTG recommendation, since your packages 
are no worse off than mine were, and those were apparently still useful 
to people. :)


Something to pursue later, having no effect on GTG status:

There's a bogus test in Doxygen's configure script, where it goes 
looking for dot(1) from GraphViz.  It does a weak check for it in a few 
common locations, and yells if it isn't there.  dot(1) being a filter, 
there isn't a huge penalty for using the native Windows version, which 
of course doesn't get installed in any of those locations.  It would be 
nice to either 1) send upstream a test using the PATH instead of a 
hardcoded list; or 2) adopt Yaakov's GraphViz package:


http://cygwin.com/ml/cygwin/2010-10/msg00232.html

Option 1 is sufficient, but option 2 means you can make graphviz a 
dependency of your doxygen package, so everyone gets it automatically.

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

[Warren Young]

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 in [1]


Lovely.

I don't see a clean solution short of demanding that everyone be on 
Automake 1.12 then.  Symlink hackery only works when you know which 
versino of Automake you are running.  I guess bootstrap.sh could detect 
Automake 1.11 and below, but ick.