Re: Moving on from Cygwin

[David Stacey]

On 26/06/18 19:34, David Stacey wrote:
Sadly, the time has come for me to step back from being a Cygwin 
package maintainer. Corinna has asked that I stay on the list for a 
while to help any prospective maintainer in adopting one or more of my 
packages, so I will remain subscribed to 'cygwin' and 'cygwin-apps' 
for at least a fortnight. 


I'm unsubscribing from the Cygwin lists now, but I leave you with 
parting gifts (see below). All are tested in both architectures, and if 
I was still maintaining these packages I would upload them. I will leave 
it to your judgement to decide whether to take them or not.


All the best,

Dave.



# gcovr-4.1 (noarch)
BASEURL=https://www.dropbox.com/s
mkdir -p noarch/release/gcovr
pushd noarch/release/gcovr
wget "${BASEURL}/ny5q6goa6xopgy9/gcovr-4.1-1-src.tar.xz"
wget "${BASEURL}/9u30xmioyxlic2v/gcovr-4.1-1.hint"
wget "${BASEURL}/v0aah48c935mq8s/gcovr-4.1-1.tar.xz"
popd



# ruby-puppet-lint-2.3.6 (noarch)
BASEURL=https://www.dropbox.com/s
mkdir -p noarch/release/ruby-puppet-lint/ruby-puppet-lint-doc
pushd noarch/release/ruby-puppet-lint
wget "${BASEURL}/dny3a4dqnl161fj/ruby-puppet-lint-2.3.6-1-src.tar.xz"
wget "${BASEURL}/cde6f42b9nnh1xu/ruby-puppet-lint-2.3.6-1.hint"
wget "${BASEURL}/rlq2bco9zym9ucy/ruby-puppet-lint-2.3.6-1.tar.xz"
cd ruby-puppet-lint-doc
wget "${BASEURL}/1q67qtbqx5yvqva/ruby-puppet-lint-doc-2.3.6-1.hint"
wget "${BASEURL}/4159ed32h994jb7/ruby-puppet-lint-doc-2.3.6-1.tar.xz"
popd



# mkvtoolnix-25.0.0 (x86)
BASEURL=https://www.dropbox.com/s
mkdir -p x86/release/mkvtoolnix/mkvtoolnix-debuginfo
mkdir -p x86/release/mkvtoolnix/mkvtoolnix-gui
pushd x86/release/mkvtoolnix
wget "${BASEURL}/bil2ods4dwzhb8t/mkvtoolnix-25.0.0-1-src.tar.xz"
wget "${BASEURL}/hli3l99i14rjoeo/mkvtoolnix-25.0.0-1.hint"
wget "${BASEURL}/agisva915of2jkh/mkvtoolnix-25.0.0-1.tar.xz"
cd mkvtoolnix-debuginfo
wget "${BASEURL}/5a9tvbjkp4ydi9d/mkvtoolnix-debuginfo-25.0.0-1.hint"
wget "${BASEURL}/5c17ovxdk06jd3a/mkvtoolnix-debuginfo-25.0.0-1.tar.xz"
cd ../mkvtoolnix-gui
wget "${BASEURL}/kb2f2jktux18dx2/mkvtoolnix-gui-25.0.0-1.hint"
wget "${BASEURL}/b1zv4fqdirbxjr6/mkvtoolnix-gui-25.0.0-1.tar.xz"
popd



# mkvtoolnix-25.0.0 (x86_64)
BASEURL=https://www.dropbox.com/s
mkdir -p x86_64/release/mkvtoolnix/mkvtoolnix-debuginfo
mkdir -p x86_64/release/mkvtoolnix/mkvtoolnix-gui
pushd x86_64/release/mkvtoolnix
wget "${BASEURL}/ypawzizaeo2y8l1/mkvtoolnix-25.0.0-1-src.tar.xz"
wget "${BASEURL}/y9ohlr3r0rmek1y/mkvtoolnix-25.0.0-1.hint"
wget "${BASEURL}/ow84ki9jqao5i60/mkvtoolnix-25.0.0-1.tar.xz"
cd mkvtoolnix-debuginfo
wget "${BASEURL}/t3zxql66ewoq7rf/mkvtoolnix-debuginfo-25.0.0-1.hint"
wget "${BASEURL}/8hus4yfx3t8oemp/mkvtoolnix-debuginfo-25.0.0-1.tar.xz"
cd ../mkvtoolnix-gui
wget "${BASEURL}/z201b1c1bho2qg0/mkvtoolnix-gui-25.0.0-1.hint"
wget "${BASEURL}/iqnqqo4sxl1b6px/mkvtoolnix-gui-25.0.0-1.tar.xz"
popd

Re: Moving on from Cygwin

[David Stacey]

On 28/06/18 13:15, Brian Inglis wrote:

On 2018-06-27 17:24, David Stacey wrote:

All of these are effectively dead upstream:
- 'words' is a dictionary from the Moby project. This doesn't exist anymore, and
so the source file is pulled from a 2006 mirror on the Wayback Machine! I
include a couple of patches from Fedora to correct some misspelled words and add
the names of US presidents.

Documented by the author at:
https://en.wikipedia.org/wiki/Moby_Project
which says mirrored at:
http://www.gutenberg.org/catalog/world/results?title=moby+list
in etexts 3201-6.


Thanks for the information. I used the same source URL as Fedora [1] - 
in fact, I just translated Fedora's 'spec' file into 'cygport' form.


Obviously, a new maintainer is free to pick whichever source of the Moby 
dictionary that he or she wishes. Note, however, that in the Gutenberg 
mirror, the files have all been renamed meaning that Fedora's 'typos' 
patch won't apply.


Dave.

[1] - https://src.fedoraproject.org/cgit/rpms/words.git/tree/words.spec

Re: Moving on from Cygwin

[David Stacey]

On 27/06/18 23:09, SPC wrote:

I have reviewed the list of packages maintained by David so far. I have
identified three packages of simple maintenance at least in appearance:

- mscgen
- ninvaders
- words


All of these are effectively dead upstream:

- The last release of 'mscgen' was in 2011. There have been a handful of 
commits since then [1], but nothing since January 2015. I carry some of 
these commits as patches. As well as being useful in its own right, 
mscgen is needed in Cygwin to provide the '\msc' command in doxygen.


- 'ninvaders' was last released in 2003(!). I include three patches - I 
neglected to note the source of these, but they were probably from Debian.


- 'words' is a dictionary from the Moby project. This doesn't exist 
anymore, and so the source file is pulled from a 2006 mirror on the 
Wayback Machine! I include a couple of patches from Fedora to correct 
some misspelled words and add the names of US presidents.


So the actual maintenance of these packages is going to be extremely 
light. There are unlikely to be any new upstream versions. You'll just 
need to rebuild them for any change in their dependencies, or to add 
patches from the major distros.



I prefer to be cautious since I do not know the rules of maintenance and
publication of packages under Cygwin. I would need to have information
about it.

On the other hand, any comment about the matter is appreciated and welcome.


Start here [2].

Hope this helps,

Dave.

[1] - https://code.google.com/archive/p/mscgen/source/default/commits
[2] - https://cygwin.com/packages.html

doxygen Notes (was: Re: Moving on from Cygwin)

[David Stacey]

On 27/06/18 11:14, Michael Wild wrote:

For me the following orphaned packages are of importance (not all of
them David's):

* doxygen

If nobody else steps up, I can adopt one or the other.


Some notes on 'doxygen' that might help you (or someone else) maintain 
the package:


doxygen is split into two packages: the main programme in 'doxygen', and 
the 'doxywizard' GUI in 'doxygen-doxywizard'. It GUI icon used for 
doxywizard is borrowed from the Fedora package and is part of kdesdk.


New doxygen releases are put out upstream once or twice a year (pay 
attention around Christmas Day!) [1]. Between releases, it's worth 
checking the patches that get applied to doxygen in a major distro, e.g 
[2], and pick up any that you feel are important.


Doxygen has it's own C++ parser, which is quite 'loose' in its 
understanding of C++. It's generally OK, but I've tripped it up in the 
past with some complex template specialisation. Thankfully, doxygen can 
be built to use clang for its parsing (although you have to explicitly 
enable this in your doxygen file [3]). I build doxygen in this way to 
give users the option of a 'better' C++ parser should they need it 
(although I'm not aware of any major distro doing likewise).


Doxygen has an experimental feature to store its internal data in an 
sqlite3 database. This is turned off, and I'm not aware of any major 
distro enabling this feature.


Doxygen fails to compile under 64-bit Cygwin with the default CFLAGS and 
CXXFLAGS as populated by cygport. The compilation fails in the assembler 
with 'too many sections'. The solution is to suppress the generation of 
the 'debuginfo' package for 64-bit, and then the compilation completes 
successfully. This doesn't affect 32-bit Cygwin, where a 'debuginfo' 
package is generated.


Hope that helps,

Dave.

[1] - http://doxygen.org/manual/changelog.html
[2] - https://src.fedoraproject.org/cgit/rpms/doxygen.git/tree/
[3] - http://doxygen.org/manual/config.html#cfg_clang_assisted_parsing

Re: Moving on from Cygwin

[David Stacey]

On 26/06/18 20:55, SPC wrote:

2018-06-26 20:34 GMT+02:00 David Stacey:


So with immediate effect, all of my packages are available for adoption.


First of all, good luck with your new projects.​


Thank you!


About the adoption of some package(s) to maintain, I have more free time
than previously, so I could assume the maintenance of at least one. We can
talk about it privately if you want, despite of other procedures to make
this effective.


The best thing to do is pick a package that you actually use (or would 
start using). I maintain quite a varied collection, so there might be 
something there that interests you! Search for my name in the link that 
Marco sent you earlier.


Let's keep our discussion to this list - it's probably best to keep 
these conversations open. And thank you for your interest in becoming a 
package maintainer!


Dave.

Moving on from Cygwin

[David Stacey]

Sadly, the time has come for me to step back from being a Cygwin package 
maintainer. I'm keen to take on a new project, and I need to free up 
some time in what is already a fairly hectic life! This has meant some 
difficult decisions about letting some things go in order to free up the 
time needed, and my work as a Cygwin package maintainer is one of the 
things I need to set aside.


So with immediate effect, all of my packages are available for adoption. 
All are (more or less) up-to-date. Corinna has asked that I stay on the 
list for a while to help any prospective maintainer in adopting one or 
more of my packages, so I will remain subscribed to 'cygwin' and 
'cygwin-apps' for at least a fortnight.


I've been a Cygwin package maintainer for nearly six years, and I've 
learned a lot in my time here. Special thanks to Corinna for leading the 
programme, and to Yaakov for somehow managing to maintain a ridiculous 
number of packages. Cygwin has made a big difference to so many users 
over the years. I know the work done here is genuinely appreciated by 
the community, and I wish the programme every success in the future.


Dave.

Re: [ITP] cmark: CommonMark parsing and rendering library

[David Stacey]

On 28/01/18 14:58, Jon Turney wrote:

On 21/01/2018 23:30, David Stacey wrote:
'cmark' is a prerequisite for the latest version of mkvtoolnix-gui. 
'cmark' is found in most major distros - see 
https://pkgs.org/download/cmark


The library does not have a 'so' version. I've had a look to see how 
the major distros cope with this, and IMHO the most sensible is found 
in openSuse. The approach used there is to append the version number 
to the library package name. However, if anyone has a better way to 
cope with the lack of 'so' number then I'd be very interested.


Many thanks for taking a look,


Looks fine to me.

I added this to your uploads.


Thanks - much appreciated.

Dave.

[ITP] cmark: CommonMark parsing and rendering library

[David Stacey]

'cmark' is a prerequisite for the latest version of mkvtoolnix-gui. 
'cmark' is found in most major distros - see https://pkgs.org/download/cmark


The library does not have a 'so' version. I've had a look to see how the 
major distros cope with this, and IMHO the most sensible is found in 
openSuse. The approach used there is to append the version number to the 
library package name. However, if anyone has a better way to cope with 
the lack of 'so' number then I'd be very interested.


Many thanks for taking a look,

Dave.


# x86
BASEURL=https://www.dropbox.com/s
mkdir -p x86/release/cmark
pushd x86/release/cmark
wget ${BASEURL}/4ajzely0nv1bqbc/cmark-0.28.3-1-src.tar.xz
wget ${BASEURL}/mftgz8eztuc468y/cmark-0.28.3-1.tar.xz
wget ${BASEURL}/b6b05lalw965ce6/cmark-0.28.3-1.hint
mkdir cmark-debuginfo cmark-devel libcmark0_28_3
cd cmark-debuginfo
wget ${BASEURL}/gqyx9k9y0qhcq3p/cmark-debuginfo-0.28.3-1.hint
wget ${BASEURL}/speysbhush1lfpa/cmark-debuginfo-0.28.3-1.tar.xz
cd ../cmark-devel
wget ${BASEURL}/7a3jp8ic8vzeu6c/cmark-devel-0.28.3-1.hint
wget ${BASEURL}/pjhjbuikst91nau/cmark-devel-0.28.3-1.tar.xz
cd ../libcmark0_28_3
wget ${BASEURL}/a5a6du0wso3lxwg/libcmark0_28_3-0.28.3-1.hint
wget ${BASEURL}/qcm34pxgamxrygb/libcmark0_28_3-0.28.3-1.tar.xz
popd


# x86_64
BASEURL=https://www.dropbox.com/s
mkdir -p x86_64/release/cmark
pushd x86_64/release/cmark
wget ${BASEURL}/1r8e32mi8hrxadj/cmark-0.28.3-1-src.tar.xz
wget ${BASEURL}/qoi79xunuvyinjt/cmark-0.28.3-1.hint
wget ${BASEURL}/r0ssovzt1m4dr0i/cmark-0.28.3-1.tar.xz
mkdir cmark-debuginfo cmark-devel libcmark0_28_3
cd cmark-debuginfo
wget ${BASEURL}/synv3v6lk9okaui/cmark-debuginfo-0.28.3-1.hint
wget ${BASEURL}/3koao7t6zw966f9/cmark-debuginfo-0.28.3-1.tar.xz
cd ../cmark-devel
wget ${BASEURL}/wlpk33vdn6ht9z0/cmark-devel-0.28.3-1.hint
wget ${BASEURL}/ny68t30s10np2t6/cmark-devel-0.28.3-1.tar.xz
cd ../libcmark0_28_3
wget ${BASEURL}/b7fs8exm6jciy8p/libcmark0_28_3-0.28.3-1.hint
wget ${BASEURL}/mns1r31qibshuvv/libcmark0_28_3-0.28.3-1.tar.xz
popd

Re: Planned setup.ini changes for early 2018

[David Stacey]

On 10/01/18 22:44, Jon Turney wrote:


* Add depends: to version descriptions
* De-duplicate source archives
* Migrate from setup.hint to pvr.hint in release area


That all sounds good to me.

Regarding the de-duplication of source files: will sources for 'noarch' 
packages remain in 'noarch', or will they move to 'src' as well?


Thanks to you and Ken for your work on setup.

Dave.

Re: AW: AW: [ITP] Mini-XML (mxml)

[David Stacey]

On 09/01/18 22:17, Stefan Köpsell wrote:

I do not plan to ITPing something which uses Mini-XML -- because it seems that 
not so many other software packages are actually depend on it. And the ones I 
found in Debian do not attract me.
But the reason I like to have the library in Cygwin is, that several of our 
projects depend on the library - and it makes contributing more easy, if the 
library is available as Cygwin package.

But I understand that this argument might not be very convincing.


I don't think that the absence of another package using MiniXML should 
necessarily exclude it from Cygwin. Historically, we've only required 
that a package be available in at least one major Linux distro, and not 
come with any non-free baggage. Besides, MiniXML has an executable 
(mxmldoc) that uses the library.


I've taken a brief look at your packages. You've created two top-level 
packages, each with its own source package, which isn't right. There 
should be one single source package that creates 'mxml' plus two 
additional sub-packages as follows:


- mxml, containing mxmldoc, its man page, 'COPYING' and 'README';
- libmxml1, containing the DLL (only); and
- libmxml-devel, containing the header files and lib.

If you want to see how to split a package into a library and devel 
sub-packages, there are probably dozens of examples in Cygwin - take a 
look at the Cygwin sources for 'tinyxml2' or 'pugixml' for inspiration. 
These are fairly simple libraries split into sub-packages.


Hope this helps,

Dave.

Re: [ITP] moreutils 0.61

[David Stacey]

On 16/11/17 15:08, Adam Dinwoodie wrote:

On Wednesday 15 November 2017 at 08:52 pm +, Tony Kelman wrote:

-   parallel: run multiple jobs at once

I'd be hesitatnt to package that since it directly clashes with GNU
parallel (not available on Cygwin yet).

Hmm.  I wasn't aware of GNU parallel, and I'm not sure how that sort of
problem is generally handled.  Possibly that could be broken out into a
separate package to make it easier for folk to install one or the other?
I considered and decided against breaking the entire lot into separate
packages, but this is perhaps a good argument for at least separating
that.

This has been a long source of tension between moreutils' author and the
debian packager (probably fedora and other distros too). I don't know off
the top of my head what solution those distros have come up with for the
name conflict but they may be doing something worth investigating and
imitating.

I have made frequent use of mispipe and ts, and would probably use other
pieces of moreutils if I remembered them better, so I'd use and appreciate
a cygwin package of them - assuming a solution is found to the potential
name conflict.

It looks like both OS X's Homebrew and Debian's Apt deal with this by
just having the packages conflict.


Several other distros do likewise: Fedora / CentOS, openSUSE, Slackware, 
Ubuntu.

See https://pkgs.org/download//usr/bin/parallel

Dave.

Re: [RFC] Minimal Debuginfo by default

[David Stacey]

On 15/11/17 07:38, Yaakov Selkowitz wrote:

The following concept would allow for sensible backtraces without
installing a -debuginfo, at the expense of a moderate size increase of
binaries (particularly with C++ code):

https://fedoraproject.org/wiki/Changes/MingwMiniDebugInfo


Did you mean https://fedoraproject.org/wiki/Features/MiniDebugInfo 
Presumably you intend this for Cygwin binaries.



The patch for cygport would be minimal.  Is it worth the size increase?


The benefit to Fedora is obvious, in that it would increase the quality 
of the automated bug reports. Do we have an equivalent in Cygwin (or is 
one planned)? Right now, we don't have so many backtraces sent in to the 
main list, but who knows - if they were easier to generate then we might.


How would this work for Cygwin? Would we require all the lib.* packages 
to be rebuilt?


Dave.

Re: Struggling to upload

[David Stacey]

On 29/09/17 23:44, Jon Turney wrote:

On 29/09/2017 23:04, David Stacey wrote:
I'm trying to upload a new version of ruby-puppet-lint, a 'noarch' 
package. I've FTP-d the files in and created a '!ready' cookie, but 
the files aren't being moved.


I've probably done something wrong - please could someone take a look.


No, this was my fault, calm stopped running due to something it 
couldn't handle.


I've restarted it, and it seems to have moved your upload (and a 
couple of others that have been sitting there since yesterday :()


Thanks very much.

Dave.

Struggling to upload

[David Stacey]

I'm trying to upload a new version of ruby-puppet-lint, a 'noarch' 
package. I've FTP-d the files in and created a '!ready' cookie, but the 
files aren't being moved.


I've probably done something wrong - please could someone take a look.

Many thanks in advance,

Dave.

Re: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian

[David Stacey]

On 10/03/17 20:24, Achim Gratz wrote:

Corinna Vinschen writes:

Otherwise, I am nervous about setting a precedent for a package that could
give different contents each time it is installed (yes, Microsoft, I'm
looking at you too). And there are plenty of corner cases where this
wouldn't work: offline installs, web proxies, or if the account performing
the Cygwin install (e.g. Administrator) was blocked from accessing the web
(on security grounds).

This is another interesting point of course.  Does wget or curl allow
to specify a (short) timeout before giving up and just not installing
anything, perhaps?


Yes. 'wget' has --timeout=. You can also set --dns-timeout, 
--connect-timeout and --read-timeout for fine-grain control [1]. 
However, the defaults are sensible and it gives up fairly quickly if 
there's no network.


'curl' has --max-time and --connect-timeout [2].


Regardless if that is possible (I think it is), I would not accept such
a package into the standard distribution.  For one, setup is not really
equipped to handle such packages properly.  Two, I really can't allow
anything to download something from outside the internal network during
the installation even where it might work.


I agree completely. I maintain what is effectively a private corporate 
Cygwin Time Machine, so the company I work for can recreate 
installations. Having this kind of repeatability is important to some 
people. In one sense I can't get too excited - it's just a documentation 
package afterall - I'm just nervous that it sets a precedent. What's 
next? Similar packages for non-free fonts? How about a package that 
downloads the 'lame' source, builds it and installs it, all from a 
post-install script? These might sound a bit extreme, but you get my point.


Dave.

[1] - https://linux.die.net/man/1/wget
[2] - https://linux.die.net/man/1/curl

Re: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian

[David Stacey]

On 06/03/17 20:42, Brian Inglis wrote:

Debian provides a SUSV4 package which downloads the tar.bz2 and installs
the HTML tree from:

	http://pubs.opengroup.org/onlinepubs/9699919799/download/  


in the postinstall script, as they believe that complies with the terms
permitting individual download stated and linked at:

http://pubs.opengroup.org/onlinepubs/terms.htm

http://www.opengroup.org/legal

Is there any interest in such a package in Cygwin, and is this approach
acceptable?


Given that no-one else has replied:

Point (2) of the T&Cs linked above state that you are required to supply 
a name and e-mail address for each publication requested. You're not 
doing that (and neither should you without user consent), and so for me 
it has to be an automatic 'No' for not complying with the T&Cs. IANAL.


Otherwise, I am nervous about setting a precedent for a package that 
could give different contents each time it is installed (yes, Microsoft, 
I'm looking at you too). And there are plenty of corner cases where this 
wouldn't work: offline installs, web proxies, or if the account 
performing the Cygwin install (e.g. Administrator) was blocked from 
accessing the web (on security grounds).


My thoughts aren't all negative though - there's clearly benefit in what 
you're trying to achieve.


Dave.

Re: [RFU] ruby-puppet-lint-2.0.2-1

[David Stacey]

On 24/11/2016 08:35, Corinna Vinschen wrote:

usr/bin/puppet-lint starts with a shebang line like this:

   #!/usr/bin/ruby.exe

.exe???

Ok, never mind.  I just realized that other ruby gems packages already come with
that, too.


How unpleasant! It looks as though the shebang is being altered by 'gem 
install'. There is a perfectly decent shebang when the gem is unpacked, 
but this gets nobbled during the install process, probably by the 
shebang() function in /usr/share/rubygems/rubygems/installer.rb 
(shebang() function starts at line 500). Ideally this should be patched 
if someone can work out how the '.exe' is creeping in, as that would fix 
all gem packages when they are rebuilt.


The other option is for each gem package to call ruby_fix_shebang() in 
src_install() of their respective cygport files. But it would be better 
to patch 'gem' if at all possible.


Anyway, thanks for taking the time to look at these packages.

Dave.

Re: [ITP] gcovr: Coverage report generator

[David Stacey]

On 15/06/16 07:12, David Stacey wrote:

gcovr is a Python script to generate reports from gcov. Found in Debian
and Ubuntu


Latest is gcovr-3.3:

BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/gcovr/gcovr-3.3-1-src.tar.xz \
${BASEURL}/gcovr/gcovr-3.3-1.tar.xz \
${BASEURL}/gcovr/setup.hint

Anyone interested in seeing this in Cygwin?

Dave.

[ITP] ruby-redcarpet

[David Stacey]

A Ruby gem for converting Mardown to HTML. Found in most popular distros 
[1].



# x86:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/x86/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-redcarpet/ruby-redcarpet-3.3.4-1-src.tar.xz \
${BASEURL}/ruby-redcarpet/ruby-redcarpet-3.3.4-1.tar.xz \
${BASEURL}/ruby-redcarpet/ruby-redcarpet-debuginfo/ruby-redcarpet-debuginfo-3.3.4-1.tar.xz 
\

${BASEURL}/ruby-redcarpet/ruby-redcarpet-debuginfo/setup.hint \
${BASEURL}/ruby-redcarpet/ruby-redcarpet-doc/ruby-redcarpet-doc-3.3.4-1.tar.xz 
\

${BASEURL}/ruby-redcarpet/ruby-redcarpet-doc/setup.hint \
${BASEURL}/ruby-redcarpet/setup.hint


# x86_64:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/x86_64/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-redcarpet/ruby-redcarpet-3.3.4-1-src.tar.xz \
${BASEURL}/ruby-redcarpet/ruby-redcarpet-3.3.4-1.tar.xz \
${BASEURL}/ruby-redcarpet/ruby-redcarpet-debuginfo/ruby-redcarpet-debuginfo-3.3.4-1.tar.xz 
\

${BASEURL}/ruby-redcarpet/ruby-redcarpet-debuginfo/setup.hint \
${BASEURL}/ruby-redcarpet/ruby-redcarpet-doc/ruby-redcarpet-doc-3.3.4-1.tar.xz 
\

${BASEURL}/ruby-redcarpet/ruby-redcarpet-doc/setup.hint \
${BASEURL}/ruby-redcarpet/setup.hint


Dave.

[1] - https://pkgs.org/search/redcarpet

[ITP] ruby-metadata-json-lint

[David Stacey]

A utility to verify Puppet 'metadata.json' files. Not found in any major 
distros, so requires votes. Really handy if required to develop Puppet 
modules on Windows.



# ruby-metadata-json-lint (noarch):
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \
${BASEURL}/ruby-metadata-json-lint/ruby-metadata-json-lint-1.0.0-1-src.tar.xz 
\

${BASEURL}/ruby-metadata-json-lint/ruby-metadata-json-lint-1.0.0-1.tar.xz \
${BASEURL}/ruby-metadata-json-lint/ruby-metadata-json-lint-doc/ruby-metadata-json-lint-doc-1.0.0-1.tar.xz 
\

${BASEURL}/ruby-metadata-json-lint/ruby-metadata-json-lint-doc/setup.hint \
${BASEURL}/ruby-metadata-json-lint/setup.hint


Plus dependencies:


# ruby-semantic_puppet (noarch):
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-semantic_puppet/ruby-semantic_puppet-0.1.4-1-src.tar.xz \
${BASEURL}/ruby-semantic_puppet/ruby-semantic_puppet-0.1.4-1.tar.xz \
${BASEURL}/ruby-semantic_puppet/ruby-semantic_puppet-doc/ruby-semantic_puppet-doc-0.1.4-1.tar.xz 
\

${BASEURL}/ruby-semantic_puppet/ruby-semantic_puppet-doc/setup.hint \
${BASEURL}/ruby-semantic_puppet/setup.hint

# ruby-gettext-setup (noarch):
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-gettext-setup/ruby-gettext-setup-0.7-1-src.tar.xz \
${BASEURL}/ruby-gettext-setup/ruby-gettext-setup-0.7-1.tar.xz \
${BASEURL}/ruby-gettext-setup/ruby-gettext-setup-doc/ruby-gettext-setup-doc-0.7-1.tar.xz 
\

${BASEURL}/ruby-gettext-setup/ruby-gettext-setup-doc/setup.hint \
${BASEURL}/ruby-gettext-setup/setup.hint

# ruby-spdx-licenses (noarch):
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-spdx-licenses/ruby-spdx-licenses-1.1.0-1-src.tar.xz \
${BASEURL}/ruby-spdx-licenses/ruby-spdx-licenses-1.1.0-1.tar.xz \
${BASEURL}/ruby-spdx-licenses/ruby-spdx-licenses-doc/ruby-spdx-licenses-doc-1.1.0-1.tar.xz 
\

${BASEURL}/ruby-spdx-licenses/ruby-spdx-licenses-doc/setup.hint \
${BASEURL}/ruby-spdx-licenses/setup.hint

# ruby-fast_gettext (noarch):
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-fast_gettext/ruby-fast_gettext-1.1.0-1-src.tar.xz \
${BASEURL}/ruby-fast_gettext/ruby-fast_gettext-1.1.0-1.tar.xz \
${BASEURL}/ruby-fast_gettext/ruby-fast_gettext-doc/ruby-fast_gettext-doc-1.1.0-1.tar.xz 
\

${BASEURL}/ruby-fast_gettext/ruby-fast_gettext-doc/setup.hint \
${BASEURL}/ruby-fast_gettext/setup.hint


Dave.

Re: [RFU] ruby-puppet-lint-2.0.2-1

[David Stacey]

On 11/11/16 00:48, David Stacey wrote:
A tool for checking (and fixing) Puppet manifests. Found in most Linux 
distros [1], including Fedora.


BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release 

wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1-src.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/ruby-puppet-lint-doc-2.0.2-1.tar.xz 
\

${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/setup.hint \
${BASEURL}/ruby-puppet-lint/setup.hint


Dave.

[1] - https://pkgs.org/search/?query=puppet-lint&type=smart



Subject: s/RFU/ITP/ Sorry - it's late here and my brain is already asleep...

Dave.

[RFU] ruby-puppet-lint-2.0.2-1

[David Stacey]

A tool for checking (and fixing) Puppet manifests. Found in most Linux 
distros [1], including Fedora.


BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1-src.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/ruby-puppet-lint-doc-2.0.2-1.tar.xz
 \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/setup.hint \
${BASEURL}/ruby-puppet-lint/setup.hint


Dave.

[1] - https://pkgs.org/search/?query=puppet-lint&type=smart

Re: [ITP] alure 1.2

[David Stacey]

On 13/10/16 18:05, Bastian Germann wrote:

it's almost 4 weeks since I submitted the package. Is there something
wrong with my email to not be answered? I think, I followed the
Contributor's Guide pretty close.

Is someone willing to review the package?


It's probably only polite for /someone/ on the list to reply, although 
in fairness I'm probably not the most qualified person to do so. You may 
be aware that Cygwin package maintainers are mostly volunteers who have 
to juggle real life (jobs, families, etc.) with Open Source work. The 
bulk of Cygwin packages are maintained by a surprisingly small number of 
individuals, and sometimes real life demands mean that there is little 
time to review new contributions. That's not to say that new packages 
aren't wanted (they are), it's just that occasionally there is no-one 
with sufficient time to undertake a review. 'alure' isn't too big, but 
any package the size of 'gambas3' is going to take quite some time to 
pick through.


The other problem with 'alure' is one of scope: I'm not sure how many 
maintainers are interested or familiar with sound on Cygwin. Yaakov or 
Marco would probably have the best knowledge to perform a review, but it 
depends on their availability. It's certainly a couple of years since I 
last dabbled with sound on Cygwin.


Dave.

Re: Request for perl-Archive-Extract

[David Stacey]

On 05/10/16 19:56, Achim Gratz wrote:

David Stacey writes:

On 29/09/16 19:42, Achim Gratz wrote:

I'll ITP that, but later.  I'll have to look what else I need to roll up
in that ITP.

Thanks very much,

Done.



Thank you,

Dave.

Re: Request for perl-Archive-Extract

[David Stacey]

On 29/09/16 19:42, Achim Gratz wrote:

David Stacey writes:

Do I take it that you'd be happy to maintain the package, or would you
prefer me to submit an ITP?

I'll ITP that, but later.  I'll have to look what else I need to roll up
in that ITP.



Thanks very much,

Dave.

Re: Request for perl-Archive-Extract

[David Stacey]

On 28/09/16 19:32, Achim Gratz wrote:

David Stacey writes:

Please could you add Archive::Extract when you next update a batch of
Perl modules. I've attached a cygport file, which you might find
helpful as a starting point. If you'd prefer not to maintain this
yourself then let me know and I'll submit an ITP.

I automatically generate all cygport files for Perl distributions…  I
have that one already locally, so it's not much work to add to Cygwin,
but may I ask what do you need it for?



The company I'm working for at the moment needs it for an internal 
script that they're developing. I've made a package for them using the 
cygport file I e-mailed earlier. However, I'd rather the package was 
available in the main repo (even if I have to maintain that package 
myself) because then I don't have to add any additional packages to the 
stock Cygwin that I download. Plus then the rest of the Cygwin community 
can benefit from it!


Do I take it that you'd be happy to maintain the package, or would you 
prefer me to submit an ITP?


Dave.

Request for perl-Archive-Extract

[David Stacey]

Achim,

Please could you add Archive::Extract when you next update a batch of 
Perl modules. I've attached a cygport file, which you might find helpful 
as a starting point. If you'd prefer not to maintain this yourself then 
let me know and I'll submit an ITP.


Many thanks in advance,

Dave.

# perl-Archive-Extract.cygport
NAME="perl-Archive-Extract"
VERSION="0.76"
RELEASE="1"
CPAN_AUTHOR="BINGOS"
SUMMARY="Generic archive extracting mechanism"
DESCRIPTION="Archive::Extract is a generic archive extraction mechanism. It 
allows you to extract any archive file of the type .tar, .tar.gz, .gz, .Z, 
tar.bz2, .tbz, .bz2, .zip, .xz,, .txz, .tar.xz, or .lzma without having to 
worry how it does so, or use different interfaces for each type by using either 
perl modules, or command-line tools on your system."
ARCH=noarch

# This perl module invokes several archiving programmes on the command line.
REQUIRES="tar unzip gzip bzip2 ncompress xz"

inherit perl

Re: calm: Unable to upload poco-1.7.5

[David Stacey]

On 07/09/16 22:47, Jon Turney wrote:

On 07/09/2016 19:30, David Stacey wrote:

I'm trying to upload poco-1.7.5 and delete poco-1.6.1-2. Part of this
involves removing the directory libpoco31, as there has been an ABI
bump, and this is where I'm failing.

I've tried creating empty '-libpoco31-1.6.1-2.tar.xz' and '-setup.hint'
files (in a bid to delete both), but calm won't let me remove a
setup.hint file. So I tried a setup.hint just containing 'skip:' and
deleting the lib package as before, but that didn't work. Finally, I
tried creating a '-libpoco31' directory, but calm wouldn't take that
either.

Please could you advise how I should delete older 'lib' sub-packages
that are no longer required.


Sorry for the inconvenience.

At the moment, there is no good way of completely removing a package, 
even when nothing depends on it.


For the moment, if you leave libpoco31-1.6.1-2 and the corresponding 
source-package alone, you should be able to proceed with your upload.


I'll make a note to clean up libpoco31 when the 'good way' of doing 
that is implemented.


Thank you for your help, Jon. I've done as you requested, leaving 
libpoco31-1.6.1-2 and its source package behind. These can be removed 
the next time someone has a tidy up.



Secondly, I'm trying to upload the noarch package 'poco-doc'. calm isn't
taking this, despite creating a '/noarch/!ready' file. I'm not getting
any helpful message from calm regarding this one - it eats the !ready
cookie, but doesn't upload the files. I've obviously made some mistake
with this one, but I can't spot it.


It looks like these were not moved as that was part of the save calm 
run as your other failures above.


calm will not move any of your uploaded package if there is a problem 
with any of them (it seems that to do otherwise could lead to an 
unexpected package set)


OK, thanks for clarifying.


I set this to be re-tried and it seems to have succeeded.



Thanks for giving it a poke. Yes, I confirm that it has been uploaded.

Dave.

calm: Unable to upload poco-1.7.5

[David Stacey]

I'm trying to upload poco-1.7.5 and delete poco-1.6.1-2. Part of this 
involves removing the directory libpoco31, as there has been an ABI 
bump, and this is where I'm failing.


I've tried creating empty '-libpoco31-1.6.1-2.tar.xz' and '-setup.hint' 
files (in a bid to delete both), but calm won't let me remove a 
setup.hint file. So I tried a setup.hint just containing 'skip:' and 
deleting the lib package as before, but that didn't work. Finally, I 
tried creating a '-libpoco31' directory, but calm wouldn't take that either.


Please could you advise how I should delete older 'lib' sub-packages 
that are no longer required.


Secondly, I'm trying to upload the noarch package 'poco-doc'. calm isn't 
taking this, despite creating a '/noarch/!ready' file. I'm not getting 
any helpful message from calm regarding this one - it eats the !ready 
cookie, but doesn't upload the files. I've obviously made some mistake 
with this one, but I can't spot it.


Please help!

Many thanks in advance,

Dave.

Re: [ITP] FUSE 2.8

[David Stacey]

On 17/07/16 02:02, Bill Zissimopoulos wrote:

The package has an
external dependency on my own open source project called WinFsp [WINFSP].
WinFsp includes the necessary kernel-mode driver that enables the
FUSE-like functionality on Windows. Unfortunately this driver can only be
built with Microsoft tools. Furthermore it must be signed with an EV
certificate (and going forward Microsoft will soon require that they sign
every kernel mode driver themselves through the sysdev portal).

For this reason you cannot simply get the source code for the FUSE cygport
and WinFsp and compile everything from scratch. This is not a licensing
issue (all code is AGPLv3), but a tools/signing issue.



IIRC, there is already precedent for this sort of thing in the Linux 
world, as boot loaders need to be signed to work with UFEI Secure Boot - 
see [1].


Dave.

[1] - https://fedoraproject.org/wiki/Secureboot

Re: [ITP] words - Dictionary file

[David Stacey]

On 14/07/16 15:56, Warren Young wrote:

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.



So are you happy for me to upload the 'words' package as it is at the 
moment?


Dave.

Re: [ITP] words - Dictionary file

[David Stacey]

On 13/07/16 14:30, Marco Atzeri wrote:

On 13/07/2016 14:57, Ken Brown wrote:

On 7/13/2016 4:17 AM, Marco Atzeri wrote:

On 13/07/2016 00:26, David Stacey wrote:

On 12/07/2016 23:22, David Stacey wrote:

My good deed for the day. See
https://cygwin.com/ml/cygwin/2016-07/msg00129.html

Based heavily on the Fedora package of the same name.


Schtoopid Thunderbird. Let's try those links again.

# noarch:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release 




wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/words/setup.hint \
${BASEURL}/words/words-3.0-1-src.tar.xz \
${BASEURL}/words/words-3.0-1.tar.xz

Dave.



it looks fine.

Added the package to cygwin-pkg-maint


This needs to be coordinated with Warren's proposal:

https://www.cygwin.com/ml/cygwin-apps/2016-07/msg00015.html

Ken



the two packages seem to provide different word lists.
In theory both can coexist



Not as they stand - both packages provide the /usr/share/dict/words symlink.

I've done a little digging. Here's where /usr/share/dict/words comes 
from on various distros:


  - words - ALT, Arch?, CentOS, Fedora, Mageia, OpenMandriva, ROSA
  - bsd-games - Slackware (that's just plain wrong!)
  - wamerican - Ubuntu
  - Not present at all - Debian?

'miscfiles' is available on Debian and Ubuntu, but nether provides the 
/usr/share/dict/words symlink.


Obviously, we don't have to follow any of that - this is just an 
observation of what other distros do.


How should Cygwin proceed? Is this a case for alternatives, or is that a 
little over the top for a dictionary? Should one of the packages drop 
the symlink? Do we need both 'miscfiles' and 'words' packages? Should we 
drop 'words' if 'miscfiles' provides a superset of the data?


Any thoughts?

Dave.

Re: [ITP] words - Dictionary file

[David Stacey]

On 12/07/2016 23:22, David Stacey wrote:
My good deed for the day. See 
https://cygwin.com/ml/cygwin/2016-07/msg00129.html


Based heavily on the Fedora package of the same name.


Schtoopid Thunderbird. Let's try those links again.

# noarch:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/words/setup.hint \
${BASEURL}/words/words-3.0-1-src.tar.xz \
${BASEURL}/words/words-3.0-1.tar.xz

Dave.

[ITP] words - Dictionary file

[David Stacey]

My good deed for the day. See 
https://cygwin.com/ml/cygwin/2016-07/msg00129.html


Based heavily on the Fedora package of the same name.

# noarch:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release 

wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/words/setup.hint \
${BASEURL}/words/words-3.0-1-src.tar.xz \
${BASEURL}/words/words-3.0-1.tar.xz


Dave.

Re: [ITP] gcovr: Coverage report generator

[David Stacey]

On 15/06/16 08:53, Marco Atzeri wrote:

On 15/06/2016 08:12, David Stacey wrote:

gcovr is a Python script to generate reports from gcov. Found in Debian
and Ubuntu [1].


# noarch:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release 


wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/gcovr/gcovr-3.2-1-src.tar.xz \
${BASEURL}/gcovr/gcovr-3.2-1.tar.xz \
${BASEURL}/gcovr/setup.hint


Test harness requires 'python-nose' and 'python-coverage' from Ports,
plus 'python-pyutilib' below. All tests pass. These are only requireed
to run the test harness; gcovr will build and run without these.



are you sure that byte compiled is arch indipendent ?

$ file usr/lib/python2.7/site-packages/gcovr/*
usr/lib/python2.7/site-packages/gcovr/__init__.py:  ASCII text
usr/lib/python2.7/site-packages/gcovr/__init__.pyc: python 2.7 
byte-compiled
usr/lib/python2.7/site-packages/gcovr/__init__.pyo: python 2.7 
byte-compiled



My understanding is that these byte-compiled files are architecture 
independent, but not Python version independent [1] [2].


Dave.

[1] - https://docs.python.org/2.7/library/marshal.html
[2] - 
https://osdir.com/ml/linux.redhat.fedora.extras.packaging/2006-07/msg00122.html

[ITP] gcovr: Coverage report generator

[David Stacey]

gcovr is a Python script to generate reports from gcov. Found in Debian
and Ubuntu [1].


# noarch:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/gcovr/gcovr-3.2-1-src.tar.xz \
${BASEURL}/gcovr/gcovr-3.2-1.tar.xz \
${BASEURL}/gcovr/setup.hint


Test harness requires 'python-nose' and 'python-coverage' from Ports,
plus 'python-pyutilib' below. All tests pass. These are only requireed
to run the test harness; gcovr will build and run without these.


# noarch:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/python-pyutilib/python-pyutilib-5.3.5-1-src.tar.xz \
${BASEURL}/python-pyutilib/python-pyutilib-5.3.5-1.tar.xz \
${BASEURL}/python-pyutilib/setup.hint


Note that I'm not offering to maintain 'python-pyutilib' (yet!), just
gcovr.

Many thanks in advance for looking at this package,

Dave.

[1] - https://pkgs.org/search/gcovr

Re: gcovr - Suitable for Cygwin?

[David Stacey]

On 06/06/16 20:18, Corinna Vinschen wrote:

On Jun  6 10:49, Corinna Vinschen wrote:

On Jun  4 19:10, David Stacey wrote:

I've been using gcovr to generate coverage reports, and I'd be happy to
maintain this for Cygwin. Before submitting a package, I'd be grateful if
someone could check the licence [1].

It's a fairly standard 3-clause BSD affair, but with the caveat that 'the
U.S. Government retains certain rights in this software.' It isn't clear (to
me, at least) what rights are being referred to. Would such a clause
prohibit its inclusion in Cygwin?

Note that gcovr isn't available for Fedora or CentOS, although this could be
because it hasn't been packaged for these distros, rather than any
incompatibility in the licence. It is, however, available for Debian and
Ubuntu [2].

Any thoughts on its suitability for Cygwin?

Let me ask somebody who knows this better than me...

Ok, nothing to worry about.  Please go ahead if you like.



Thank you for checking. I'll prepare a package later this week.

Dave.

gcovr - Suitable for Cygwin?

[David Stacey]

I've been using gcovr to generate coverage reports, and I'd be happy to 
maintain this for Cygwin. Before submitting a package, I'd be grateful 
if someone could check the licence [1].


It's a fairly standard 3-clause BSD affair, but with the caveat that 
'the U.S. Government retains certain rights in this software.' It isn't 
clear (to me, at least) what rights are being referred to. Would such a 
clause prohibit its inclusion in Cygwin?


Note that gcovr isn't available for Fedora or CentOS, although this 
could be because it hasn't been packaged for these distros, rather than 
any incompatibility in the licence. It is, however, available for Debian 
and Ubuntu [2].


Any thoughts on its suitability for Cygwin?

Dave.

[1] https://raw.githubusercontent.com/gcovr/gcovr/master/LICENSE.txt
[2] https://pkgs.org/search/gcovr

Re: [ITP] poco-doc: Documentation package for Poco

[David Stacey]

On 30/05/16 09:47, Corinna Vinschen wrote:

On May 30 09:18, David Stacey wrote:

On 17/05/16 23:12, David Stacey wrote:

BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release

wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/poco-doc/libpoco-doc/libpoco-doc-1.7.3-1.tar.xz \
${BASEURL}/poco-doc/libpoco-doc/setup.hint \
${BASEURL}/poco-doc/poco-doc-1.7.3-1-src.tar.xz \
${BASEURL}/poco-doc/poco-doc-1.7.3-1.tar.xz \
${BASEURL}/poco-doc/setup.hint



I hope you don't mind a gentle nudge! This is just repackaging what was
already in Cygwin anyway, so it shouldn't take too much time to check. I'd
like to upload poco-1.7.3, but can't until 'poco-doc' is added to
cygwin-package-maint as a top-level package.

Done.  Please go ahead.



Thanks!

Dave.

Re: [ITP] poco-doc: Documentation package for Poco

[David Stacey]

On 17/05/16 23:12, David Stacey wrote:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release 

wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco-doc/libpoco-doc/libpoco-doc-1.7.3-1.tar.xz \
${BASEURL}/poco-doc/libpoco-doc/setup.hint \
${BASEURL}/poco-doc/poco-doc-1.7.3-1-src.tar.xz \
${BASEURL}/poco-doc/poco-doc-1.7.3-1.tar.xz \
${BASEURL}/poco-doc/setup.hint



I hope you don't mind a gentle nudge! This is just repackaging what was 
already in Cygwin anyway, so it shouldn't take too much time to check. 
I'd like to upload poco-1.7.3, but can't until 'poco-doc' is added to 
cygwin-package-maint as a top-level package.


Many thanks in advance,

Dave.

[ITP] poco-doc: Documentation package for Poco

[David Stacey]

The Poco documentation used to be libpoco-doc, a child package of poco, 
but I would like to spin it out into its own package. This will make it 
easier to maintain, and as a top-level package it can be marked as 
'noarch'. I have taken the opportunity to update Poco to the latest version:



BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco-doc/libpoco-doc/libpoco-doc-1.7.3-1.tar.xz \
${BASEURL}/poco-doc/libpoco-doc/setup.hint \
${BASEURL}/poco-doc/poco-doc-1.7.3-1-src.tar.xz \
${BASEURL}/poco-doc/poco-doc-1.7.3-1.tar.xz \
${BASEURL}/poco-doc/setup.hint


If you are happy with this, please add 'poco-doc' to 
cygwin-package-maint as a top-level package, so I can upload.


The rest of this e-mail is for information. For the inquisitive, here is 
the corresponding version of Poco, built without documentation:



# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/x86/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco/libpoco-devel/libpoco-devel-1.7.3-1.tar.xz \
${BASEURL}/poco/libpoco-devel/setup.hint \
${BASEURL}/poco/libpoco43/libpoco43-1.7.3-1.tar.xz \
${BASEURL}/poco/libpoco43/setup.hint \
${BASEURL}/poco/poco-1.7.3-1-src.tar.xz \
${BASEURL}/poco/poco-1.7.3-1.tar.xz \
${BASEURL}/poco/poco-debuginfo/poco-debuginfo-1.7.3-1.tar.xz \
${BASEURL}/poco/poco-debuginfo/setup.hint \
${BASEURL}/poco/setup.hint

# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/x86_64/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco/libpoco-devel/libpoco-devel-1.7.3-1.tar.xz \
${BASEURL}/poco/libpoco-devel/setup.hint \
${BASEURL}/poco/libpoco43/libpoco43-1.7.3-1.tar.xz \
${BASEURL}/poco/libpoco43/setup.hint \
${BASEURL}/poco/poco-1.7.3-1-src.tar.xz \
${BASEURL}/poco/poco-1.7.3-1.tar.xz \
${BASEURL}/poco/poco-debuginfo/poco-debuginfo-1.7.3-1.tar.xz \
${BASEURL}/poco/poco-debuginfo/setup.hint \
${BASEURL}/poco/setup.hint


I have also rebuilt Poco 1.6.1 with the documentation split out into a 
separate package. This will be uploaded first, and then immediately 
bumped into 'prev' by version 1.7.3 above:



# Documentation (architecture independent):
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco-doc/libpoco-doc/libpoco-doc-1.6.1-1.tar.xz \
${BASEURL}/poco-doc/libpoco-doc/setup.hint \
${BASEURL}/poco-doc/poco-doc-1.6.1-1-src.tar.xz \
${BASEURL}/poco-doc/poco-doc-1.6.1-1.tar.xz \
${BASEURL}/poco-doc/setup.hint

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/x86/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco/libpoco-devel/libpoco-devel-1.6.1-2.tar.xz \
${BASEURL}/poco/libpoco-devel/setup.hint \
${BASEURL}/poco/libpoco31/libpoco31-1.6.1-2.tar.xz \
${BASEURL}/poco/libpoco31/setup.hint \
${BASEURL}/poco/poco-1.6.1-2-src.tar.xz \
${BASEURL}/poco/poco-1.6.1-2.tar.xz \
${BASEURL}/poco/poco-debuginfo/poco-debuginfo-1.6.1-2.tar.xz \
${BASEURL}/poco/poco-debuginfo/setup.hint \
${BASEURL}/poco/setup.hint

# x86_64:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/x86_64/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/poco/libpoco-devel/libpoco-devel-1.6.1-2.tar.xz \
${BASEURL}/poco/libpoco-devel/setup.hint \
${BASEURL}/poco/libpoco31/libpoco31-1.6.1-2.tar.xz \
${BASEURL}/poco/libpoco31/setup.hint \
${BASEURL}/poco/poco-1.6.1-2-src.tar.xz \
${BASEURL}/poco/poco-1.6.1-2.tar.xz \
${BASEURL}/poco/poco-debuginfo/poco-debuginfo-1.6.1-2.tar.xz \
${BASEURL}/poco/poco-debuginfo/setup.hint \
${BASEURL}/poco/setup.hint


This will ensure that both 'curr' and 'prev' versions of Poco are built 
in the same way.


Dave.

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

[David Stacey]

On 11/05/16 21:15, Yaakov Selkowitz wrote:

On 2016-05-11 11:26, David Stacey wrote:

On 11/05/16 07:17, Yaakov Selkowitz wrote:

On 2016-05-11 00:07, Marco Atzeri wrote:

So at this stage not the documentation subpackages, but only if all
subpackages are in this category. correct ?


At this time we are only considering those where all subpackages are
noarch, i.e. ARCH=noarch is (or will be) defined.


Is it worth making libpoco-doc a separate package? It might be cleaner
that way, as the documentation and source code are in different tarballs
upstream.


Your call, it doesn't appear that anything is gained from building it 
together with poco itself.  I'd name the sources poco-doc and either:


OBSOLETES=libpoco-doc

or:

PKG_NAMES="libpoco-doc"
libpoco_doc_CONTENTS="usr/share/doc/poco/html/"



Thank you for your advice. I think I'd like to split the documentation 
into a separate package, as it will make it easier to maintain. As I'm 
creating a new top-level package, I'll send an ITP separately.


Dave.

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

[David Stacey]

On 11/05/16 07:17, Yaakov Selkowitz wrote:

On 2016-05-11 00:07, Marco Atzeri wrote:

So at this stage not the documentation subpackages, but only if all
subpackages are in this category. correct ?


At this time we are only considering those where all subpackages are 
noarch, i.e. ARCH=noarch is (or will be) defined.



Is it worth making libpoco-doc a separate package? It might be cleaner 
that way, as the documentation and source code are in different tarballs 
upstream.


Dave.

Re: [ITP] ghex - GNOME hex editor

[David Stacey]

On 17/09/15 18:11, Yaakov Selkowitz wrote:

On Tue, 2015-09-15 at 21:53 +0100, David Stacey wrote:

ghex is a hex editor for GNOME, found in most Linux distros [1], and I'd
like to see it in Cygwin too.

Yaakov: As ghex is currently available in Ports, yours is first refusal.
If you'd like to maintain ghex yourself, please could you bring ghex and
its child packages across from Ports. However, if you're happy for me to
maintain it, then my packages are as follows:

I copied the Ports packages into the distro, so they should show up
soon.


Much appreciated - many thanks.

Dave.

[ITP] ghex - GNOME hex editor

[David Stacey]

ghex is a hex editor for GNOME, found in most Linux distros [1], and I'd 
like to see it in Cygwin too.


Yaakov: As ghex is currently available in Ports, yours is first refusal. 
If you'd like to maintain ghex yourself, please could you bring ghex and 
its child packages across from Ports. However, if you're happy for me to 
maintain it, then my packages are as follows:



# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ghex/ghex-3.17.91-1-src.tar.xz \
${BASEURL}/ghex/ghex-3.17.91-1.tar.xz \
${BASEURL}/ghex/ghex-debuginfo/ghex-debuginfo-3.17.91-1.tar.xz \
${BASEURL}/ghex/ghex-debuginfo/setup.hint \
${BASEURL}/ghex/libgtkhex3-devel/libgtkhex3-devel-3.17.91-1.tar.xz \
${BASEURL}/ghex/libgtkhex3-devel/setup.hint \
${BASEURL}/ghex/libgtkhex3_0/libgtkhex3_0-3.17.91-1.tar.xz \
${BASEURL}/ghex/libgtkhex3_0/setup.hint \
${BASEURL}/ghex/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ghex/ghex-3.17.91-1-src.tar.xz \
${BASEURL}/ghex/ghex-3.17.91-1.tar.xz \
${BASEURL}/ghex/ghex-debuginfo/ghex-debuginfo-3.17.91-1.tar.xz \
${BASEURL}/ghex/ghex-debuginfo/setup.hint \
${BASEURL}/ghex/libgtkhex3-devel/libgtkhex3-devel-3.17.91-1.tar.xz \
${BASEURL}/ghex/libgtkhex3-devel/setup.hint \
${BASEURL}/ghex/libgtkhex3_0/libgtkhex3_0-3.17.91-1.tar.xz \
${BASEURL}/ghex/libgtkhex3_0/setup.hint \
${BASEURL}/ghex/setup.hint


Please let me know whether you'd prefer to maintain ghex yourself, or 
you'd like me to take it - I'm happy either way.


Dave.

[1] - http://pkgs.org/search/ghex

Re: Poco: Please remove empty directories

[David Stacey]

On 10/08/15 22:49, Yaakov Selkowitz wrote:

On Mon, 2015-08-10 at 22:29 +0100, David Stacey wrote:

With the release of poco-1.6.1, I've decided to do some housekeeping
and remove some of the earlier versions. I've managed to do this, but
it has left some empty directories lying around. Please could some
kind soul remove the following:

  x86_64/release/poco/libpoco16/
  x86_64/release/poco/libpoco17/
  x86/release/poco/libpoco17/

Done.


Thanks,

Dave.

Poco: Please remove empty directories

[David Stacey]

With the release of poco-1.6.1, I've decided to do some housekeeping and 
remove some of the earlier versions. I've managed to do this, but it has 
left some empty directories lying around. Please could some kind soul 
remove the following:


x86_64/release/poco/libpoco16/
x86_64/release/poco/libpoco17/
x86/release/poco/libpoco17/

Is there a way I can remove directories myself, or should I continue to 
ask here in future?


Many thanks in advance,

Dave.

Re: [ITP] znc 1.6.0

[David Stacey]

On 23/07/15 00:03, David Stacey wrote:
That's because there's no 'libznc-1.6.dll.a' to link against. You need 
to add the following to your link command when producing the shared DLL:


-Wl,--out-implib=libznc-1.6.dll.a

Again, I'll leave it to you to get this into the Makefile in a nice 
way. I'd reiterate what others have said: This should be called 
libznc#.dll, where '#' is a number that increments when the ABI 
breaks. This is our naming convention; please adhere to it. You should 
add this 'dll.a' file to your devel package. For the sake of changing 
as little of your Makefiles as possible, I left it as libznc-1.6.dll.a.


Sorry, that's wrong. DLL should be versioned, 'dll.a' lib file should be 
unversioned.


Dave.

[Why don't we notice these things /before/ clicking Send?]

Re: [ITP] znc 1.6.0

[David Stacey]

On 22/07/2015 00:53, Alexey Sokolov wrote:

David, how did you try to build it? What was the exact error message?
What do you change in Makefile.in to get it working?


Attempting to compile znc-1.6.0-3 with cygport under Cygwin x86. It's 
worth saying that my Cygwin installation is about a month old, but that 
shouldn't matter.


cygport ./znc.cygport prep compile

Nothing out of the ordinary there. This gives the following error:

configure.ac:255: Something is trying to use the C compiler. Since 
this is a C++ project, this should not happen!

autom4te-2.69: /usr/bin/m4 failed with exit status: 1

So, for the sake of not falling at the first hurdle, I skipped the 
autoreconf step by adding the following lines to znc.cygport:


src_compile() {
  cd ${B}
  cygconf
  cygmake -j 1 V=1
}

I'll leave it to you to have a more detailed poke around as to why 
atoreconf is failing. Anyway, with that in place we get a little 
further. The first hint that anything is wrong comes when we try to link 
the perl module:


/usr/lib/gcc/i686-pc-cygwin/4.9.2/../../../../i686-pc-cygwin/bin/ld: 
cannot find -lznc-1.6


That's because there's no 'libznc-1.6.dll.a' to link against. You need 
to add the following to your link command when producing the shared DLL:


-Wl,--out-implib=libznc-1.6.dll.a

Again, I'll leave it to you to get this into the Makefile in a nice way. 
I'd reiterate what others have said: This should be called libznc#.dll, 
where '#' is a number that increments when the ABI breaks. This is our 
naming convention; please adhere to it. You should add this 'dll.a' file 
to your devel package. For the sake of changing as little of your 
Makefiles as possible, I left it as libznc-1.6.dll.a.


Building again, we don't actually get any further. When linking the perl 
module, there are a stack of linker errors:


modperl.o: In function `ZN10CPerlTimerD2Ev':
/usr/src/debug/znc-1.6.0-3/modules/modperl.cpp:277: undefined 
reference to `CTimer::GetModule() const'


and screenfulls of similar output. This is because your arguments to the 
linker are in the wrong order. This doesn't matter on Linux, but it does 
on Cygwin. You need to put the '-lznc-1.6' after your object files. This 
gets the perl module compiling, and you'll have exactly the same 
problems with the python. I gave up at this point; I didn't attempt to 
test the binaries produced.


The problem I have with this is that I see no way that this could ever 
have compiled under Cygwin. How are you building this?


I hope the above doesn't come across as too critical - these comments 
are intended to be constructive, and I hope you find them helpful.


Dave.

Re: [ITP] znc 1.6.0

[David Stacey]

On 21/07/2015 08:12, Corinna Vinschen wrote:

On Jul 20 19:58, Alexey Sokolov wrote:

Well, in that case 1.6 works fine. When 1.7.0 will be released, the
filename will be changed to cygznc-1.7.dll.

Assuming 1.7 does not break the ABI.  The problem here is that modules
built for 1.6 won't run on 1.7, even if the ABI hasn't changed, because
these modules won't find the DLL anymore.  In this case your update
to a newer package would break self-built modules for no good reason.


I've had a busy day and I'm a little tired, so I'm probably about to 
make a fool of myself on a public mailing list. Never mind :-) Three 
points on the znc package:


  - Unless I've missed something, all this talk of DLL naming is a 
little academic at the moment, as there is no 'dll.a' file to actually 
link against.


  - Has anyone tried building this in Cygwin? I tried rebuilding the 
1.6.0-2 release, and couldn't get it to compile without hacking the 
'Makefile.in' files. Even if you generate a 'dll.a', the linker 
arguments are in the wrong order. This doesn't matter in Linux, but it 
/does/ matter in Cygwin. Does this only build if cross-compiled out of 
Fedora?


  - Forgive me for being pedantic, but who gave this a GTG? I couldn't 
find one on this thread, and yet the package is up on the mirrors.


Let's hope I've missed something really obvious - apologies for any 
late-night stupidity.


Dave.

Re: [ITP] foobillard - OpenGL snooker / pool game

[David Stacey]

On 25/06/15 03:38, Yaakov Selkowitz wrote:

On Wed, 2015-06-24 at 21:21 +0100, David Stacey wrote:

Built this to try out SDL that was added to Cygwin recently. Sadly,
performance of the game is rather disappointing compared to the native
Linux version running on the same hardware. Consequently, you might
decide that this is not appropriate for Cygwin just yet, or it might
only have value as a benchmarking aid for Cygwin/X. Or you might
consider that the performance is actually pretty impressive, given the
number of emulation layers involved:-)

I didn't try comparing it to Linux, but it seemed playable to me.  You
may want to try enabling direct hardware-accelerated rendering[1] in
multiwindow mode, e.g.:

DISPLAY=:0 LIBGL_USE_WGL=1 foobillard

[1]http://x.cygwin.com/docs/ug/using-aiglx.html


Thanks for the hint. My word - what an incredible difference that makes! 
On the rather modest machine I was testing with, that must have 
increased the framerate tenfold. I have included that tip in the 
announcement.


Dave.

Re: [ITP] foobillard - OpenGL snooker / pool game

[David Stacey]

On 25/06/2015 03:38, Yaakov Selkowitz wrote:

GTG, thanks.  Please upload whenever you're ready.


Please could you update cygwin-pkg-maint, as Yaakov is listed as 
maintainer and this is stopping me uploading.


Many thanks in advance,

Dave.

Re: [ITA] foobillard - OpenGL snooker / pool game

[David Stacey]

Subject line: s/ITA/ITP/ - sorry.

[ITA] foobillard - OpenGL snooker / pool game

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/foobillard/foobillard-3.0a-1-src.tar.xz \
${BASEURL}/foobillard/foobillard-3.0a-1.tar.xz \
${BASEURL}/foobillard/foobillard-debuginfo/foobillard-debuginfo-3.0a-1.tar.xz 
\

${BASEURL}/foobillard/foobillard-debuginfo/setup.hint \
${BASEURL}/foobillard/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/foobillard/foobillard-3.0a-1-src.tar.xz \
${BASEURL}/foobillard/foobillard-3.0a-1.tar.xz \
${BASEURL}/foobillard/foobillard-debuginfo/foobillard-debuginfo-3.0a-1.tar.xz 
\

${BASEURL}/foobillard/foobillard-debuginfo/setup.hint \
${BASEURL}/foobillard/setup.hint


Built this to try out SDL that was added to Cygwin recently. Sadly,
performance of the game is rather disappointing compared to the native
Linux version running on the same hardware. Consequently, you might
decide that this is not appropriate for Cygwin just yet, or it might
only have value as a benchmarking aid for Cygwin/X. Or you might
consider that the performance is actually pretty impressive, given the
number of emulation layers involved :-)

This is the 'hobbled' version from Fedora with the non-free fonts
removed. As per Fedora, DejaVu-Sans has been substituted, so you will
need font-dejavu-ttf from CygwinPorts. Yaakov: If foobillard is
accepted into Cygwin, would you mind awfully bringing this font package
over, please?

There are two other patches, both from Fedora.

Feel free to reject this on performance grounds if you think it is
unplayable. However, if someone gets some enjoyment out of it then I'm
happy to maintain it.

Dave.

Re: [ITP] pugixml - A lightweight C++ XML processing library

[David Stacey]

On 01/06/15 19:37, Yaakov Selkowitz wrote:

On Sat, 2015-05-30 at 12:21 +0100, David Stacey wrote:

pugixml is a lightweight C++ XML processing library. It is present in
most Linux distros [1] and is a dependency of mkvtoolnix. Fedora and
Centos both name the library package pugixml rather than libpugixml, and
that naming has been used here (although I could change it if there is
strong opinion). Packaging based on Fedora.

Please leave the source package as pugixml, but change the binary
packages to libpugixml1 and libpugixml-devel.  With that change, GTG.


Thank you for taking the time to look at this. I will make the changes 
you requested and then upload.


Dave.

[ITP] mkvtoolnix - Tools for manipulating Matroska files

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/mkvtoolnix/mkvtoolnix-7.9.0-1-src.tar.xz \
${BASEURL}/mkvtoolnix/mkvtoolnix-7.9.0-1.tar.xz \
${BASEURL}/mkvtoolnix/mkvtoolnix-debuginfo/mkvtoolnix-debuginfo-7.9.0-1.tar.xz 
\

${BASEURL}/mkvtoolnix/mkvtoolnix-debuginfo/setup.hint \
${BASEURL}/mkvtoolnix/mkvtoolnix-gui/mkvtoolnix-gui-7.9.0-1.tar.xz \
${BASEURL}/mkvtoolnix/mkvtoolnix-gui/setup.hint \
${BASEURL}/mkvtoolnix/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/mkvtoolnix/mkvtoolnix-7.9.0-1-src.tar.xz \
${BASEURL}/mkvtoolnix/mkvtoolnix-7.9.0-1.tar.xz \
${BASEURL}/mkvtoolnix/mkvtoolnix-debuginfo/mkvtoolnix-debuginfo-7.9.0-1.tar.xz 
\

${BASEURL}/mkvtoolnix/mkvtoolnix-debuginfo/setup.hint \
${BASEURL}/mkvtoolnix/mkvtoolnix-gui/mkvtoolnix-gui-7.9.0-1.tar.xz \
${BASEURL}/mkvtoolnix/mkvtoolnix-gui/setup.hint \
${BASEURL}/mkvtoolnix/setup.hint


mkvtoolnix is a collection of tools for manipulating Matroska files 
(*.mkv, *.mka). It features command line utilities and a GUI front end. 
It requires libebml [1], libmatroska [2] and pugixml [3].


mkvtoolnix is present is most Linux distros [4]. Packaging is based on 
Fedora. GUI package contains both wx-widgets and Qt variants. I may 
split this into two separate packages, depending on how Fedora package 
their version.


Dave.

[1] - http://cygwin.com/ml/cygwin-apps/2015-05/msg00088.html
[2] - http://cygwin.com/ml/cygwin-apps/2015-05/msg00089.html
[3] - http://cygwin.com/ml/cygwin-apps/2015-05/msg00090.html
[4] - http://pkgs.org/search/mkvtoolnix

[ITP] pugixml - A lightweight C++ XML processing library

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/pugixml/pugixml-1.6-1-src.tar.xz \
${BASEURL}/pugixml/pugixml-debuginfo/pugixml-debuginfo-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml-debuginfo/setup.hint \
${BASEURL}/pugixml/pugixml-devel/pugixml-devel-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml-devel/setup.hint \
${BASEURL}/pugixml/pugixml-doc/pugixml-doc-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml-doc/setup.hint \
${BASEURL}/pugixml/pugixml1/pugixml1-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml1/setup.hint \
${BASEURL}/pugixml/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/pugixml/pugixml-1.6-1-src.tar.xz \
${BASEURL}/pugixml/pugixml-debuginfo/pugixml-debuginfo-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml-debuginfo/setup.hint \
${BASEURL}/pugixml/pugixml-devel/pugixml-devel-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml-devel/setup.hint \
${BASEURL}/pugixml/pugixml-doc/pugixml-doc-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml-doc/setup.hint \
${BASEURL}/pugixml/pugixml1/pugixml1-1.6-1.tar.xz \
${BASEURL}/pugixml/pugixml1/setup.hint \
${BASEURL}/pugixml/setup.hint


pugixml is a lightweight C++ XML processing library. It is present in 
most Linux distros [1] and is a dependency of mkvtoolnix. Fedora and 
Centos both name the library package pugixml rather than libpugixml, and 
that naming has been used here (although I could change it if there is 
strong opinion). Packaging based on Fedora.


Dave.

[1] - http://pkgs.org/search/pugixml

[ITP] libmatroska - Open audio/video container format library

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/libmatroska/libmatroska-1.4.2-1-src.tar.xz \
${BASEURL}/libmatroska/libmatroska-debuginfo/libmatroska-debuginfo-1.4.2-1.tar.xz 
\

${BASEURL}/libmatroska/libmatroska-debuginfo/setup.hint \
${BASEURL}/libmatroska/libmatroska-devel/libmatroska-devel-1.4.2-1.tar.xz \
${BASEURL}/libmatroska/libmatroska-devel/setup.hint \
${BASEURL}/libmatroska/libmatroska6/libmatroska6-1.4.2-1.tar.xz \
${BASEURL}/libmatroska/libmatroska6/setup.hint \
${BASEURL}/libmatroska/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/libmatroska/libmatroska-1.4.2-1-src.tar.xz \
${BASEURL}/libmatroska/libmatroska-debuginfo/libmatroska-debuginfo-1.4.2-1.tar.xz 
\

${BASEURL}/libmatroska/libmatroska-debuginfo/setup.hint \
${BASEURL}/libmatroska/libmatroska-devel/libmatroska-devel-1.4.2-1.tar.xz \
${BASEURL}/libmatroska/libmatroska-devel/setup.hint \
${BASEURL}/libmatroska/libmatroska6/libmatroska6-1.4.2-1.tar.xz \
${BASEURL}/libmatroska/libmatroska6/setup.hint \
${BASEURL}/libmatroska/setup.hint


libmatroska is a C++ library to parse Matroska files (*.mkv, *.mka). It 
requires libebml [1].


libmatroska is present in most Linux distros [2]. It's also present in 
Cygwin Ports, albeit at an earlier version, so Yaakov should have first 
refusal at maintaining this. However, mkvtoolnix needs to be built 
against a very specific version of libmatroska, so it makes sense for 
the same person to maintain both packages.



Dave.

[1] - http://cygwin.com/ml/cygwin-apps/2015-05/msg00088.html
[2] - http://pkgs.org/search/libmatroska

[ITP] libebml - Extensible Binary Meta Language library

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/libebml/libebml-1.3.1-1-src.tar.xz \
${BASEURL}/libebml/libebml-debuginfo/libebml-debuginfo-1.3.1-1.tar.xz \
${BASEURL}/libebml/libebml-debuginfo/setup.hint \
${BASEURL}/libebml/libebml-devel/libebml-devel-1.3.1-1.tar.xz \
${BASEURL}/libebml/libebml-devel/setup.hint \
${BASEURL}/libebml/libebml4/libebml4-1.3.1-1.tar.xz \
${BASEURL}/libebml/libebml4/setup.hint \
${BASEURL}/libebml/setup.hint

# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/libebml/libebml-1.3.1-1-src.tar.xz \
${BASEURL}/libebml/libebml-debuginfo/libebml-debuginfo-1.3.1-1.tar.xz \
${BASEURL}/libebml/libebml-debuginfo/setup.hint \
${BASEURL}/libebml/libebml-devel/libebml-devel-1.3.1-1.tar.xz \
${BASEURL}/libebml/libebml-devel/setup.hint \
${BASEURL}/libebml/libebml4/libebml4-1.3.1-1.tar.xz \
${BASEURL}/libebml/libebml4/setup.hint \
${BASEURL}/libebml/setup.hint


libebml is a library for reading and writing files with the Extensible 
Binary Meta Language, a binary pendant to XML. It is a dependency of 
mkvtoolnix.


libebml is present in most Linux distros [1]. It's also present in 
Cygwin Ports, albeit at an earlier version, so Yaakov should have first 
refusal at maintaining this. However, mkvtoolnix needs to be built 
against a very specific version of libebml, so it makes sense for the 
same person to maintain both packages.


Dave.

[1] - http://pkgs.org/search/libebml

[ITP] mkvtoolnix and its dependencies

[David Stacey]

Recently, I had to process some video files [1] in the 'mkv' container 
format, and used mkvtoolnix for this purpose. I'm happy to maintain it 
in case it is useful to anyone else. There are four packages involved; 
I'll send separate ITP e-mails for each.


Dave.

[1] - Home movies, obviously ;-)

Re: perl-5.22.0-RC2 / Perl distributions

[David Stacey]

On 26/05/15 06:32, Achim Gratz wrote:

David Stacey writes:

I downloaded this with the intention of building perl-Text-CSV_XS and
perl-Text-CSV, but discovered that you'd built them already! I'm more
than happy for you to build these packages for the sake of
transitioning to a new release of perl, but I'd like to keep
maintenance of them, at least for the time being.

I needed those for other stuff, so I went ahead and built it.  If you'd
rather want to upload the new packages yourself, that's one more person
to coordinate the upload with, which I think we will manage.  You will
have to rebuild the package once more before the upload when the final
version of Perl is available.


Thanks for your e-mail. I'm very happy for you to upload perl-Text-CSV 
and perl-Text-CSV_XS for the purposes of getting the new version of perl 
rolled out.


Dave.

Re: perl-5.22.0-RC2 / Perl distributions

[David Stacey]

On 24/05/15 21:02, Achim Gratz wrote:

I've built perl-5.22.0-RC2 and bootstrapped the Perl distributions for
Cygwin (well, most of them -- I will send another ITA for some
additional ones I've hat to build later).  It doesn't make much sense to
try a test release on sourceware, so I've uploaded to my own server,
which you can use (in addition to) the normal package archive(s):

setup-{x86,x86_64}.exe -XOshttp://cygwin.stromeko.net/


I downloaded this with the intention of building perl-Text-CSV_XS and 
perl-Text-CSV, but discovered that you'd built them already! I'm more 
than happy for you to build these packages for the sake of transitioning 
to a new release of perl, but I'd like to keep maintenance of them, at 
least for the time being.


Dave.

Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2

[David Stacey]

On 26/02/2015 11:58, Thomas Wolff wrote:

On 25.02.2015 21:34, David Stacey wrote:

On 25/02/2015 07:27, Thomas Wolff wrote:

Am 19.02.2015 um 00:05 schrieb David Stacey:

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from Fedora.

Please rebuild the package with
configure --with-freetype
so the font selection option -F can be used.


I tried rebuilding with '--with-freetype'. mscgen builds but always 
exits with an error code. This is because gdImageStringFT() always 
returns the string 'Could not set character size'. By default, the 
code is trying to use the 'helvetica' font. I have a goodly selection 
of font packages installed. Any ideas?
I had similar problems until I found out how to configure fonts. This 
is very poorly documented.
With /etc/fonts/fonts.conf pointing to ~/.fonts, it is actually 
sufficient to link your font directory to ~/.fonts
and you can address all fonts contained therein (including subfolders) 
by their name like in

mscgen -T png -F "Droid Sans"


I'm not sure you need to edit /etc/fonts/fonts.conf. By default, this 
includes /usr/share/fonts, so any font therein should be accessible to 
mscgen. You would only need to do this if you wanted to use fonts in 
non-standard locations - such as those from texlive-collection-fontsextra.


I wonder if this is a problem with font types? 'fc-match helvetica' 
matches a PCF font, and that might explain the error, if libgd3 is 
trying to scale a bitmap font. But a TrueType Font such as 'Luxi Sans' 
works. Should I just patch mscgen so that the default font is a TrueType 
font?


Dave.

Re: UTF32 crash in poco-1.6.0 - Request for help

[David Stacey]

On 25/02/15 23:07, Achim Gratz wrote:

David Stacey writes:

I'm still trying to get to the bottom of this. The UTF16 test (the one
that works) uses std::wstring, but the UTF32 test (the one that
crashes) uses a custom string made with a 32-bit integer and
corresponding traits class. If the UTF16 test is switched from using
std::wstring to a similar custom string type then this also crashes.

It would be easy to blame the custom string types, except that I can
isolate the code in a stand-alone example that works fine. Plus, I've
compiled Poco on Fedora 21 with the two custom string types, and again
everything works fine.

I tried compiling with all optimisation turned off, and now the code
still crashes, just more slowly:-)  I was hoping that I might get
something more sensible out of gdb with -O0, but alas no. The next
step is to produce a static build (again with all optimisation
disabled) and then cut bits out of it until I come up with a minimal
programme that exhibits the bug.

Is that code trying to switch encoding in any way?  There's a bug in
Perl (only 64bit) that throws a SEGV when doing that…


Thanks for your reply. I'll keep that in mind, but the crash I'm seeing 
occurs on both architectures.


Dave.

Re: UTF32 crash in poco-1.6.0 - Request for help

[David Stacey]

On 18/02/15 12:09, David Stacey wrote:
The test causing the crash is the UnicodeConverterTest 
(Foundation/testsuite/src/UnicodeConverterTest.cpp). This is 
templated, and is instantiated with both UTF16 and UTF32 strings. The 
UTF16 case works correctly; it is the UTF32 instantiation that is 
crashing.


I'm still trying to get to the bottom of this. The UTF16 test (the one 
that works) uses std::wstring, but the UTF32 test (the one that crashes) 
uses a custom string made with a 32-bit integer and corresponding traits 
class. If the UTF16 test is switched from using std::wstring to a 
similar custom string type then this also crashes.


It would be easy to blame the custom string types, except that I can 
isolate the code in a stand-alone example that works fine. Plus, I've 
compiled Poco on Fedora 21 with the two custom string types, and again 
everything works fine.


I tried compiling with all optimisation turned off, and now the code 
still crashes, just more slowly :-) I was hoping that I might get 
something more sensible out of gdb with -O0, but alas no. The next step 
is to produce a static build (again with all optimisation disabled) and 
then cut bits out of it until I come up with a minimal programme that 
exhibits the bug.


Dave.

Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2

[David Stacey]

On 25/02/2015 07:27, Thomas Wolff wrote:

Am 19.02.2015 um 00:05 schrieb David Stacey:

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from Fedora.

Please rebuild the package with
configure --with-freetype
so the font selection option -F can be used.


I tried rebuilding with '--with-freetype'. mscgen builds but always 
exits with an error code. This is because gdImageStringFT() always 
returns the string 'Could not set character size'. By default, the code 
is trying to use the 'helvetica' font. I have a goodly selection of font 
packages installed. Any ideas?


Dave.

[ITA] mscgen - Message Sequence Chart rendering programme

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/mscgen/mscgen-0.20-2-src.tar.xz \
${BASEURL}/mscgen/mscgen-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/mscgen-debuginfo-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/setup.hint \
${BASEURL}/mscgen/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/mscgen/mscgen-0.20-2-src.tar.xz \
${BASEURL}/mscgen/mscgen-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/mscgen-debuginfo-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/setup.hint \
${BASEURL}/mscgen/setup.hint


Rebuilt using libgd3, with three patches from Fedora [1].

Dave.

[1] - https://apps.fedoraproject.org/packages/mscgen/sources/patches

UTF32 crash in poco-1.6.0 - Request for help

[David Stacey]

e022582115c10879-3936-sigwait
   66   55806 [main] testrunner 3936 fhandler_pipe::create: pipe write handle 
0x7C
   48   55854 [main] testrunner 3936 dll_crt0_0: finished dll_crt0_0 
initialization
22903   78757 [sig] testrunner 3936 wait_sig: entering ReadFile loop, 
my_readsig 0x78, my_sendsig 0x7C
  133   78890 [main] testrunner 3936 time: 1424252168 = time(0x0)
   83   78973 [main] testrunner 3936 mount_info::conv_to_posix_path: 
conv_to_posix_path 
(D:\Dave\Linux\Cygwin64\cygwin_auto_maintainer\poco\poco-1.6.0-1.x86_64\build\Foundation\testsuite\bin\CYGWIN\x86_64,
 no-keep-rel, no-add-slash)
   44   79017 [main] testrunner 3936 normalize_win32_path: 
D:\Dave\Linux\Cygwin64\cygwin_auto_maintainer\poco\poco-1.6.0-1.x86_64\build\Foundation\testsuite\bin\CYGWIN\x86_64
 = normalize_win32_path 
(D:\Dave\Linux\Cygwin64\cygwin_auto_maintainer\poco\poco-1.6.0-1.x86_64\build\Foundation\testsuite\bin\CYGWIN\x86_64)
   28   79045 [main] testrunner 3936 mount_info::conv_to_posix_path: 
/cygdrive/d/Dave/Linux/Cygwin64/cygwin_auto_maintainer/poco/poco-1.6.0-1.x86_64/build/Foundation/testsuite/bin/CYGWIN/x86_64
 = conv_to_posix_path 
(D:\Dave\Linux\Cygwin64\cygwin_auto_maintainer\poco\poco-1.6.0-1.x86_64\build\Foundation\testsuite\bin\CYGWIN\x86_64)
   47   79092 [main] testrunner 3936 sigprocmask: 0 = sigprocmask (0, 0x0, 
0x600018128)
18416   97508 [main] testrunner 3936 _cygwin_istext_for_stdio: fd 0: not open
   41   97549 [main] testrunner 3936 _cygwin_istext_for_stdio: fd 1: not open
   20   97569 [main] testrunner 3936 _cygwin_istext_for_stdio: fd 2: not open
  100   97669 [main] testrunner (3936) open_shared: name cygpid.3936, n 3936, 
shared 0x18001 (wanted 0x18001), h 0xA0, *m 2
   34   97703 [main] ? (3936) time: 1424252168 = time(0x0)
   24   97727 [main] testrunner 3936 pinfo::thisproc: myself dwProcessId 3936
  102   97829 [main] testrunner 3936 environ_init: GetEnvironmentStrings 
returned 0x3F7B10
   42   97871 [main] testrunner 3936 environ_init: 0x6000284F0: !::=::\
   35   97906 [main] testrunner 3936 environ_init: 0x600028510: 
ALLUSERSPROFILE=C:\ProgramData
   36   97942 [main] testrunner 3936 environ_init: 0x600028540: 
APPDATA=C:\Users\David Stacey\AppData\Roaming
   40   97982 [main] testrunner 3936 environ_init: 0x600028580: CC=gcc
   43   98025 [main] testrunner 3936 environ_init: 0x6000285A0: CFLAGS=-ggdb 
-O2 -pipe -Wimplicit-function-declaration 
-fdebug-prefix-map=/cygdrive/D/Dave/Linux/Cygwin64/cygwin_auto_maintainer/poco/poco-1.6.0-1.x86_64/build=/usr/src/debug/poco-1.6.0-1
 
-fdebug-prefix-map=/cygdrive/D/Dave/Linux/Cygwin64/cygwin_auto_maintainer/poco/poco-1.6.0-1.x86_64/src/poco-1.6.0-all=/usr/src/debug/poco-1.6.0-1
   40   98065 [main] testrunner 3936 environ_init: 0x600028700: 
COMMONPROGRAMFILES=C:\Program Files\Common Files
   37   98102 [main] testrunner 3936 environ_init: 0x600028740: 
COMPUTERNAME=FLUFFY
   36   98138 [main] testrunner 3936 environ_init: 0x600028760: 
COMSPEC=C:\Windows\system32\cmd.exe
   36   98174 [main] testrunner 3936 environ_init: 0x600028790: CXX=g++
   42   98216 [main] testrunner 3936 environ_init: 0x6000287B0: CXXFLAGS=-ggdb 
-O2 -pipe 
-fdebug-prefix-map=/cygdrive/D/Dave/Linux/Cygwin64/cygwin_auto_maintainer/poco/poco-1.6.0-1.x86_64/build=/usr/src/debug/poco-1.6.0-1
 
-fdebug-prefix-map=/cygdrive/D/Dave/Linux/Cygwin64/cygwin_auto_maintainer/poco/poco-1.6.0-1.x86_64/src/poco-1.6.0-all=/usr/src/debug/poco-1.6.0-1
   39   98255 [main] testrunner 3936 environ_init: 0x6000288F0: 
CYGPORT_ARCH=x86_64
   37   98292 [main] testrunner 3936 environ_init: 0x600028910: 
CYGPORT_BUILD_ROOT=/cygdrive/D/Dave/Linux/Cygwin64/cygwin_auto_maintainer/poco/poco-1.6.0-1.x86_64/inst
   36   98328 [main] testrunner 3936 environ_init: 0x600028990: 
CYGPORT_OPT_FLAGS=-ggdb -O2 -pipe -Wimplicit-function-declaration
   48   98376 [main] testrunner 3936 environ_init: 0x6000289E0: 
CYGPORT_OS=Cygwin
   56   98432 [main] testrunner 3936 environ_init: 0x600028A00: 
CYGPORT_PACKAGE_NAME=poco
   37   98469 [main] testrunner 3936 environ_init: 0x600028A30: 
CYGPORT_PACKAGE_RELEASE=1
   37   98506 [main] testrunner 3936 environ_init: 0x600028A60: 
CYGPORT_PACKAGE_VERSION=1.6.0
   37   98543 [main] testrunner 3936 environ_init: 0x600028A90: 
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
   36   98579 [main] testrunner 3936 environ_init: 0x600028AE0: 
CommonProgramW6432=C:\Program Files\Common Files
   43   98622 [main] testrunner 3936 parse_options: glob (called func)
   38   98660 [main] testrunner 3936 parse_options: returning
   19   98679 [main] testrunner 3936 environ_init: 0x600028B20: CYGWIN=noglob
   36   98715 [main] testrunner 3936 environ_init: 0x600028B60: EXECIGNORE=*.dll
   35   98750 [main] testrunner 3936 environ_init: 0x600028B80: F77=gfortran
   34   98784 [main] testrunner 3936 environ_init: 0x600028BA0: FC=gfortran
   41   98825 [main] testrunner 3936 environ_init: 0x600028BC0: FCFLAGS=-ggdb 
-O2 -pipe 
-fdebug-prefix-map=/cygdrive/D/Dave/Li

Re: HEADSUP: Packages with obsolete dependencies

[David Stacey]

On 11/02/15 04:14, Yaakov Selkowitz wrote:

I just cleared out a huge number of obsolete and stale packages.  More
remain, but the following packages currently depend on one or more
obsolete libraries (including the recently-obsoleted libpng15 and
libgd2):

mscgen   Michael McTernan


I built mscgen for x86_64 [1], just to add a 64-bit version until 
Michael was able to supply his own build (which never happened). I'd be 
happy to rebuild for both architectures if you like - just let me know.


Dave.

[1] - http://cygwin.com/ml/cygwin-apps/2013-09/msg00016.html

Re: perl-5.14.4

[David Stacey]

On 04/02/15 20:41, Achim Gratz wrote:

If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks.


In readiness for the new perl test package, I've removed the test 
version of perl-Text-CSV_XS that was linked against perl-5.18.2.


Dave.

Re: [HEADSUP] Moving setup sources to git

[David Stacey]

On 10/02/15 18:53, Achim Gratz wrote:

David Stacey writes:

For the last ten months, I've been running the Coverity Scan static
analyser over Cygwin snapshots. Do you want me to continue using the
snapshots, or would you prefer me to switch to git master? Would there
be much difference between the two?

I think just cygwin setup has been converted to Git… see
https://sourceware.org/git/


OK, sorry. My confusion.

Dave.

Re: [HEADSUP] Moving setup sources to git

[David Stacey]

On 09/02/15 16:24, Corinna Vinschen wrote:

I just created a git repo for setup:

   git clone cygwin.com:/git/cygwin-setup.git


For the last ten months, I've been running the Coverity Scan static 
analyser over Cygwin snapshots. Do you want me to continue using the 
snapshots, or would you prefer me to switch to git master? Would there 
be much difference between the two?


Dave.

Re: perl-5.14.4

[David Stacey]

On 04/02/15 20:41, Achim Gratz wrote:

If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks.  Comments or suggestions?


Do you expect the XS modules built against 5.14.2 to be compatible with 
5.14.4, or would you like them rebuilt?


Dave.

Re: Setup patch to keep test version if test version installed

[David Stacey]

On 25/01/15 17:20, Corinna Vinschen wrote:

Instead of always defaulting to the curr version, Setup now checks if
the installed version of a package is higher than the curr version of
the package.


This sounds like a great idea - providing that the logic to compare two 
version numbers is sufficiently clever. Looking at operator<() in 
package_version.cc, it appears as though this is performing simple 
string comparison on the version numbers. This would fail in a number of 
cases. A real example from setup.ini:


package: at-spi2-atk
curr: 2.10.2-1
prev: 2.8.1-1

A simple string comparison would prefer prev over curr!

In your patch, maybe it could be better to call 
packageversion::compareVersions() rather than use operator<(). I'm not 
terribly familiar with the setup code, so please excuse me if I'm 
mistaken, got lost in the code, or am completely barking up the wrong tree.


Dave.

Re: [HEADSUP] Dropping libopenssl098 from distro

[David Stacey]

On 14/01/15 14:13, Corinna Vinschen wrote:

The following packages have dependecies of their own, so they can't
go away until the dependent packages have been rebuilt:

   libpqMarco Atzeri

 required by:

xemacs  Dr. Volker Zell


Some time ago, there was a problem rebuilding xemacs [1]. Is this still 
an issue?


Dave.

[1] - https://cygwin.com/ml/cygwin-apps/2013-08/msg00248.html

Re: [HEADSUP] Base category

[David Stacey]

On 06/12/14 21:19, Achim Gratz wrote:

Maybe what we should consider is removing the 'Select required
packages (RECOMMENDED)' check box on the 'Resolving Dependencies' page
in the installer. Under what use case is unticking this a sensible
idea?

Since setup doesn't have something like soft dependencies or recommends,
you can sometimes avoid pulling in large parts of the distribution by
skipping one key dependency (like Perl, for instance).  That will give
you reduced functionality of course, but if you know what you're doing
it may be what you really want.


Ah, fair enough. Some folk like to keep a minimal install.

Dave.

Re: [HEADSUP] Base category

[David Stacey]

On 06/12/2014 18:52, Andrew Schulman wrote:

isn't it rather annoying that even Base packages have dependencies
outside the Base category?  So, even if I perform a plain Base-only
installation, I get asked if dependencies shall be fullfilled, which, as
a question, is more than borderline anyway.

Therefore, shouldn't we put all packages Base packages depend on into
Base as well?

I can't find it in the archives now, but a year or two ago we talked about
this in the context of libargp.  There's a Base package (can't remember
which one) that depends on libargp.  But the consensus at the time was that
we shouldn't put libargp into Base, because if the other package stopped
requiring it, it wouldn't belong there on its own.

So if we're talking about permanently adding those other packages to the
Base category, I don't agree.  But it we're talking about adding them to
Base automatically only as long as another Base package requires them, then
I guess that's fine.


I have to agree with Andrew here. Dependencies change, so decide what 
should be in 'Base' and let dependencies be pulled in as required. I 
have never been overly concerned that there are dependencies outside of 
'Base'.


Maybe what we should consider is removing the 'Select required packages 
(RECOMMENDED)' check box on the 'Resolving Dependencies' page in the 
installer. Under what use case is unticking this a sensible idea?


Dave.

Re: HEADSUP Maintainers: Stale packages on sourceware

[David Stacey]

On 29/10/14 13:42, Yaakov Selkowitz wrote:
Please find attached a list of old package tarballs which are not 
listed anywhere in setup.ini, meaning that they are not listed as a 
previous, current, or test package, and cannot be installed with 
setup.  These files consume a total of over 1.3Gib.


Do maintainers have any objections to these being removed?


Thank you for looking into this. I'm happy for older versions of my 
packages to be removed.


Cheers,

Dave.

Re: [ITP] tinyxml2 - A simple, small and efficient C++ XML parser

[David Stacey]

On 29/09/14 07:58, Marco Atzeri wrote:

please move

usr/share/
usr/share/doc/
usr/share/doc/Cygwin/
usr/share/doc/Cygwin/tinyxml2.README
usr/share/doc/tinyxml2/
usr/share/doc/tinyxml2/README.md


from libtinyxml2_2 to libtinyxml2-devel
On the lib package we put only the dll's and data needed by
them to work.

Other than that GTG from me.


Thank you for your feedback. I have moved the documentation into the 
'devel' package as requested. I have updated the original download links 
should you wish to check the packaging once more. Otherwise, please 
could someone add an entry for 'tinyxml2' to cygwin-pkg-maint and I will 
upload.


Many thanks once again,

Dave.

Re: [ITA] cppcheck-1.66-1

[David Stacey]

On 22/09/14 05:03, Yaakov Selkowitz wrote:

On 2014-09-21 14:28, David Stacey wrote:

I would like to adopt cppcheck, which was orphaned by Chris Sutcliffe
last week [1]. The following notes may be of use when reviewing this
package:

I have enabled custom rules for cppcheck, which gives the user the scope
to create custom checks. This introduces a dependency on libpcre1.

I have built the Qt GUI for cppcheck, which is available as a
sub-package. cppcheck-gui is available in openSUSE [2] and ArchLinux 
[3].


The gui code is built without proper optimization or debuginfo. This 
can be fixed in gui/gui.pro:


-CONFIG += warn_on debug
+CONFIG += warn_on


cppcheck-gui contains a number of language translations, which are
included. However, the way that the GUI locates these translations is a
little bizarre. The user is expected to call 'cppcheck-gui
--data-dir=/path/to/translations' before using cppcheck-gui for the
first time. This would be an ideal candidate for a post-install step,
except that it has to be done by each user (not just the user performing
the install), and an X server needs to be running (even though no window
is opened). So for both of these reasons I consider that a post-install
step is not the way forward.

Instead, I have patched the GUI to always look for the translation files
in a set directory. This seems sensible, as you should just have one set
of translation files that are shared between all users. This works, but
the GUI gives a harmless warning the first time it is invoked. This is
probably a bug in the cppcheck-gui code, as the native Windows version
does the same. Otherwise, the GUI works well.


Not a blocker, but I suspect you're going to get "bug" reports due to 
that first-run warning message, so it would be good if you could 
eventually figure that out.


One other thing: as a graphical program it should have a desktop menu 
entry, which can be accomplished by appending the following to your 
src_install():


newicon ${S}/gui/icon.png cppcheck.png
make_desktop_entry cppcheck-gui "Cppcheck" cppcheck "Development"

and adding usr/share/applications/ and usr/share/pixmaps/ to 
cppcheck_gui_CONTENTS.


Thank you for such constructive comments, Yaakov. I have a new build of 
cppcheck with the following changes:


  - All of Yaakov's suggestions have been included (hopefully!).

  - I have tracked down and patched the bug that was causing the 
warning when cppcheck-gui was launched for the first time. This was 
caused by the application not detecting the English locale correctly. 
This is fixed and the warning is not generated in this build; I will try 
to send this patch upstream.


  - cppcheck now links dynamically with libtinyxml2_2, rather than a 
static link with a bundled version of tinyxml2. This is in line with how 
cppcheck is packaged on Fedora, Debian and their offspring. I sent a 
separate ITP for tinyxml2 to this list earlier [1].


Download links are as follows:


# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/cppcheck/cppcheck-1.66-1-src.tar.xz \
${BASEURL}/cppcheck/cppcheck-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/setup.hint \
${BASEURL}/cppcheck/cppcheck-gui/cppcheck-gui-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-gui/setup.hint \
${BASEURL}/cppcheck/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/cppcheck/cppcheck-1.66-1-src.tar.xz \
${BASEURL}/cppcheck/cppcheck-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/setup.hint \
${BASEURL}/cppcheck/cppcheck-gui/cppcheck-gui-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-gui/setup.hint \
${BASEURL}/cppcheck/setup.hint


Don't forget that you will also require tinyxml2 - see the ITP e-mail 
for links [1].


Many thanks once again for looking at this,

Dave.

[1] - https://cygwin.com/ml/cygwin-apps/2014-09/msg00040.html

[ITP] tinyxml2 - A simple, small and efficient C++ XML parser

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/tinyxml2/libtinyxml2-devel/libtinyxml2-devel-2.1.0-1.tar.xz \
${BASEURL}/tinyxml2/libtinyxml2-devel/setup.hint \
${BASEURL}/tinyxml2/libtinyxml2_2/libtinyxml2_2-2.1.0-1.tar.xz \
${BASEURL}/tinyxml2/libtinyxml2_2/setup.hint \
${BASEURL}/tinyxml2/setup.hint \
${BASEURL}/tinyxml2/tinyxml2-2.1.0-1-src.tar.xz \
${BASEURL}/tinyxml2/tinyxml2-debuginfo/setup.hint \
${BASEURL}/tinyxml2/tinyxml2-debuginfo/tinyxml2-debuginfo-2.1.0-1.tar.xz


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/tinyxml2/libtinyxml2-devel/libtinyxml2-devel-2.1.0-1.tar.xz \
${BASEURL}/tinyxml2/libtinyxml2-devel/setup.hint \
${BASEURL}/tinyxml2/libtinyxml2_2/libtinyxml2_2-2.1.0-1.tar.xz \
${BASEURL}/tinyxml2/libtinyxml2_2/setup.hint \
${BASEURL}/tinyxml2/setup.hint \
${BASEURL}/tinyxml2/tinyxml2-2.1.0-1-src.tar.xz \
${BASEURL}/tinyxml2/tinyxml2-debuginfo/setup.hint \
${BASEURL}/tinyxml2/tinyxml2-debuginfo/tinyxml2-debuginfo-2.1.0-1.tar.xz


cppcheck comes bundled with a statically linked version of tinyxml2. 
However,

a number of major distros (CentOS, Debian, Fedora, Ubuntu) package tinyxml2
separately, and their versions of cppcheck link dynamically against 
that. This
is the approach I would like to take with Cygwin. Needless to say, 
tinyxml2 is

found in the repos mentioned above [1].

This is not the most recent version of tinyxml2, but the same version that
cppcheck-1.66 statically links against. The next release of cppcheck is
expected to take the latest version of tinyxml2 [2], so I will update 
tinyxml2

when cppcheck-1.67 is released.

Many thanks in advance for looking at this package,

Dave.

[1] - http://pkgs.org/search/tinyxml2
[2] - 
https://github.com/danmar/cppcheck/commit/9bdeea56424d87cc28fba85b503ed9512f85

Re: cygport 0.17.0: Incorrect 'requires' line in setup.hint

[David Stacey]

On 26/09/2014 17:57, Marco Atzeri wrote:

On 25/09/2014 22:05, David Stacey wrote:

I am trying to package tinyxml2, to be used by cppcheck. I have split
the package into a library package called 'libtinyxml2-2', and a devel
package 'libtinyxml2-devel'. However, when I run cygport to generate the
packages, the setup.hint file for the devel package claims that it is
dependent on 'libtinyxml2' (note the missing '-2' at the end).


the package should be called libtinyxml2_2


That fixed it - thank you for your help.

Cheers,

Dave.

cygport 0.17.0: Incorrect 'requires' line in setup.hint

[David Stacey]

I am trying to package tinyxml2, to be used by cppcheck. I have split 
the package into a library package called 'libtinyxml2-2', and a devel 
package 'libtinyxml2-devel'. However, when I run cygport to generate the 
packages, the setup.hint file for the devel package claims that it is 
dependent on 'libtinyxml2' (note the missing '-2' at the end).


I've obviously done something wrong in either my package naming or in 
the cygport file itself - please could you advise. I am running 
cygport-0.17.0 in x86 Cygwin.


Many thanks in advance,

Dave.

# tinyxml2.cygport
NAME="tinyxml2"
VERSION=2.1.0
RELEASE=1
SUMMARY="Simple, small and efficient C++ XML parser."
DESCRIPTION="TinyXML-2 is a simple, small, efficient, C++ XML parser that can 
be easily integrated into other programs. It uses a Document Object Model 
(DOM), meaning the XML data is parsed into a C++ objects that can be browsed 
and manipulated, and then written to disk or another output stream.
TinyXML-2 doesn't parse or use DTDs (Document Type Definitions) nor XSLs 
(eXtensible Stylesheet Language).
TinyXML-2 uses a similar API to TinyXML-1, But the implementation of the parser 
was completely re-written to make it more appropriate for use in a game. It 
uses less memory, is faster, and uses far fewer memory allocations."
CATEGORY="Devel"

HOMEPAGE="http://www.grinninglizard.com/tinyxml2/";
GIT_URI="https://github.com/leethomason/tinyxml2";
GIT_TAG="${VERSION}"
inherit git
inherit cmake


#
# Determine the tinyxml2 library version. This is contained in a file called
# 'CMakeLists.txt' - but we might not have downloaded those yet. So get the
# library version number direct from github.
LIBRARY_VERSION=$(wget --quiet --no-check-certificate --output-document=- 
https://raw.githubusercontent.com/leethomason/tinyxml2/${VERSION}/CMakeLists.txt
 | grep "GENERIC_LIB_SOVERSION" | grep "set" | head -n 1 | cut -d '"' -f 2)
#


#
# This cygport file produces two packages: the main 'libtinyxml2' package
# that contains the files necessary to run applications built with tinyxml2;
# and 'libtinyxml2-devel', which contains header files and libs required to
# build applications that use tinyxml2.
PKG_NAMES="libtinyxml2-${LIBRARY_VERSION} libtinyxml2-devel"
#


#
# Details for the 'libtinyxml2' package.
declare libtinyxml2_${LIBRARY_VERSION}_SUMMARY="${SUMMARY}"
declare libtinyxml2_${LIBRARY_VERSION}_DESCRIPTION="${DESCRIPTION}"
declare libtinyxml2_${LIBRARY_VERSION}_CONTENTS="usr/bin usr/share"
declare libtinyxml2_${LIBRARY_VERSION}_CATEGORY="Devel"
#


#
# Details for the 'libtinyxml2-devel' package.
libtinyxml2_devel_SUMMARY="Development files for tinyxml2."
libtinyxml2_devel_DESCRIPTION="This package contains the libraries and header 
files that are needed for writing applications with the tinyxml2 library."
libtinyxml2_devel_CONTENTS="usr/include usr/lib"
libtinyxml2_devel_CATEGORY="Devel"
#


#
# Disable the generation of a static library and package only the dynamically
# linked version of tinyxml2. If doing this, we have to define our own
# install rule to ensure that the lib file gets installed.
CYGCMAKE_ARGS="-DBUILD_STATIC_LIBS=OFF"
src_install() {
cd ${B}
cyginstall
dolib *.dll.a
}
#


src_test() {
cd ${B}
./test
}

[ITA] cppcheck-1.66-1

[David Stacey]

# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \
${BASEURL}/cppcheck/cppcheck-1.66-1-src.tar.xz \
${BASEURL}/cppcheck/cppcheck-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/setup.hint \
${BASEURL}/cppcheck/cppcheck-gui/cppcheck-gui-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-gui/setup.hint \
${BASEURL}/cppcheck/setup.hint



# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \
${BASEURL}/cppcheck/cppcheck-1.66-1-src.tar.xz \
${BASEURL}/cppcheck/cppcheck-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-debuginfo/setup.hint \
${BASEURL}/cppcheck/cppcheck-gui/cppcheck-gui-1.66-1.tar.xz \
${BASEURL}/cppcheck/cppcheck-gui/setup.hint \
${BASEURL}/cppcheck/setup.hint


I would like to adopt cppcheck, which was orphaned by Chris Sutcliffe 
last week [1]. The following notes may be of use when reviewing this 
package:


I have enabled custom rules for cppcheck, which gives the user the scope 
to create custom checks. This introduces a dependency on libpcre1.


I have built the Qt GUI for cppcheck, which is available as a 
sub-package. cppcheck-gui is available in openSUSE [2] and ArchLinux [3].


cppcheck-gui contains a number of language translations, which are 
included. However, the way that the GUI locates these translations is a 
little bizarre. The user is expected to call 'cppcheck-gui 
--data-dir=/path/to/translations' before using cppcheck-gui for the 
first time. This would be an ideal candidate for a post-install step, 
except that it has to be done by each user (not just the user performing 
the install), and an X server needs to be running (even though no window 
is opened). So for both of these reasons I consider that a post-install 
step is not the way forward.


Instead, I have patched the GUI to always look for the translation files 
in a set directory. This seems sensible, as you should just have one set 
of translation files that are shared between all users. This works, but 
the GUI gives a harmless warning the first time it is invoked. This is 
probably a bug in the cppcheck-gui code, as the native Windows version 
does the same. Otherwise, the GUI works well.


The cppcheck build scripts from openSUSE [4] and ArchLinux [5] don't 
offer much inspiration - neither ship with the translation files at all, 
which will just give an error when the user tries to switch languages. 
So I would be very interested if anyone could find a more elegant 
solution to this problem.


Finally, cppcheck contains a version of tinyxml2, which it statically 
links against. Fedora has libtinyxml2 as a separate package, and their 
version of cppcheck is dependant upon that. This build of cppcheck for 
Cygwin contains the statically linked tinyxml2. However, it is my 
intention to ITP libtinyxml2 as a separate package for future builds of 
cppcheck to use.


Many thanks in advance for looking at this package,

Dave.

[1] - https://cygwin.com/ml/cygwin/2014-09/msg00289.html
[2] - 
http://www.rpmseek.com/rpm/cppcheck-gui-1.63-2.4.x86_64.html?hl=com&cs=cpp:PN:0:0:1:0:0:13516864

[3] - https://www.archlinux.org/packages/community/i686/cppcheck/
[4] - 
https://build.opensuse.org/package/view_file/devel:tools/cppcheck/cppcheck.spec
[5] - 
https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/cppcheck

Re: perl-5.18.2-1

[David Stacey]

On 15/08/14 22:15, Yaakov Selkowitz wrote:

Where did we leave off wrt breaking out
perl_vendor?


Back in April, Reini expressed a desire to keep perl_vendor, claiming 
that it is the easiest solution for both user and maintainer [1].


Whilst there are some of us who might question this, Reini has vastly 
more knowledge and experience of perl than I ever will have. So when 
Reini states that there are good reasons why perl_vendor should stay, I 
am prepared to respect his judgement.


As our perl maintainer wishes to keep perl_vendor, any discussion to the 
contrary seems somewhat academic.


Dave.

[1] https://cygwin.com/ml/cygwin-apps/2014-04/msg00015.html

Re: upset messages

[David Stacey]

On 11/08/14 23:11, cygwin-no-re...@cygwin.com wrote:

upset: couldn't unlink /sourceware/cygwin-staging/home/David Stacey/x86/!ready 
- No such file or directory



I'm not sure what happened here - apologies if it was my fault. I was 
attempting to upload new versions of xmlstarlet and yasm, both of which 
appear to have been taken. I've also checked both my 'x86' and 'x86_64' 
directories, and the '!ready' files appear to have disappeared - so 
hopefully these upset errors won't get generated ad infinitum.


Does anyone have any idea as to what could have caused this?

Dave.

[ITA] xloadimage

[David Stacey]

xloadimage is an X11 image viewer and processor. The Cygwin package was 
orphaned by Jari earlier this month [1].



# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/xloadimage/setup.hint \
${BASEURL}/xloadimage/xloadimage-4.1-2-src.tar.xz \
${BASEURL}/xloadimage/xloadimage-4.1-2.tar.xz \
${BASEURL}/xloadimage/xloadimage-debuginfo/setup.hint \
${BASEURL}/xloadimage/xloadimage-debuginfo/xloadimage-debuginfo-4.1-2.tar.xz


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/xloadimage/setup.hint \
${BASEURL}/xloadimage/xloadimage-4.1-2-src.tar.xz \
${BASEURL}/xloadimage/xloadimage-4.1-2.tar.xz \
${BASEURL}/xloadimage/xloadimage-debuginfo/setup.hint \
${BASEURL}/xloadimage/xloadimage-debuginfo/xloadimage-debuginfo-4.1-2.tar.xz


xloadimage hasn't been updated for 20 years, and is effectively 
maintained out of Debian with a growing number of patches, some of which 
are quite substantial. xloadimage is (almost entirely) obsoleted by 
ImageMagick, but there are some legacy image formats that xloadimage 
supports that ImageMagick does not. So for this reason it deserves at 
least one more outing.


xloadimage is still found in Debian, Fedora and their respective 
offshoots [2].


This build has the latest patch set from Debian (29 in total), one patch 
from Fedora, and a patch of my own making that fixes the CMUWM image 
handling in 64-bit. Packaging is through cygport, and is heavily 
inspired by the Fedora 'spec' file.


This is the first build of xloadimage for 64-bit. However, for my own 
sanity, the build number is '-2' for both architectures.


Many thanks in advance for looking at this package,

Dave.

[1] - https://cygwin.com/ml/cygwin-apps/2014-06/msg00045.html
[2] - http://pkgs.org/search/xloadimage

Re: UPDATE: cygwin-64bit-missing

[David Stacey]

On 12/06/14 17:20, Jari Aalto wrote:

[*] package has been uploaded to x64 (2014-06-12)
*  


Please could you check '' as I'm not seeing this package listed for 
x86_64:

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=&arch=x86_64

Many thanks,

Dave.

Re: O: xloadimage -- Graphics file viewer under X11

[David Stacey]

On 12/06/14 12:30, Jari Aalto wrote:

I'm orphaning package "xloadimage". If anyone feels
insterested in taking over, please go ahead.


I've got this to compile under x86_64 using the latest patch set from 
Debian. With 30 patches applied, you wonder how much of the original 
source code is still there :-) Anyway, it seems to work. I'll take a 
look at the Fedora patches and see if any of those are applicable.


I'm going to be rather busy over the next few days, but if I'm happy 
with the build then I'll send an ITA next week.


Dave.

Re: [ITP] AtomicParsley

[David Stacey]

On 04/06/2014 00:32, Yaakov Selkowitz wrote:

On 2014-06-03 14:05, David Stacey wrote:

AtomicParsley is a utility for reading and writing metadata tags on MP4
files. It is found in many Linux distros, including Fedora [1].

The package name has been capitalised to reflect the name of the
executable and to mirror the Fedora package name. Debian and Ubuntu both
use the lowercase 'atomicparsley' for the package name, but keep the
executable as 'AtomicParsley'. Personally, I prefer the Fedora
convention, but I'm happy to change this if there's precedent elsewhere.


Generally we base this on the tarball name, but I see there aren't 
anymore.  The old (<=0.9.0) tarballs were CamelCased, but the hg repo 
is lowercase (go figure).  Under the circumstances, I'd say it's up to 
you.


Thank you for taking the time to look at this. I think I would prefer to 
keep with 'AtomicParsley', as this reflects the executable name.



Finally, I've been asked in the past to provide man pages for
executables in my packages. AtomicParsley doesn't come with a man page,
so I've generated one using help2man(1). I'm tempted to drop the man
page though - even the Debian build comes without a man page these days
[2].


help2man only provides good output if --help itself follows certain 
conventions; AtomicParsley does not.  Since we don't really have a 
policy to *require* manpages where they don't already exist (this 
isn't Debian), and the resulting manpage doesn't look all that 
readable anyway, I suggest you just drop it.


It's gone. I wasn't overly keen on the man page either :-)

As for the actual build, you should drop src_compile() and use the 
default cygautoreconf/cygconf/cygmake combination. Cygwin-specific 
READMEs are optional, so you may drop that too if you wish.  Otherwise 
this looks GTG.


As per your suggestion I have dropped src_compile(). I've also removed 
my custom src_install() - I don't need this since I'm not installing a 
man page anymore. I've kept the Cygwin-specific README, as this is 
generated and it would be more work to remove it than keep it.


If you're happy with this then please could you (or CGF) add an entry 
for AtomicParsley to cygwin-pkg-maint. I'll give the new build one last 
test tomorrow and then upload it.


Thanks again for your constructive suggestions,

Dave.

[ITP] AtomicParsley

[David Stacey]

AtomicParsley is a utility for reading and writing metadata tags on MP4 
files. It is found in many Linux distros, including Fedora [1].



# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/AtomicParsley/AtomicParsley-0.9.6-1-src.tar.xz \
${BASEURL}/AtomicParsley/AtomicParsley-0.9.6-1.tar.xz \
${BASEURL}/AtomicParsley/AtomicParsley-debuginfo/AtomicParsley-debuginfo-0.9.6-1.tar.xz 
\

${BASEURL}/AtomicParsley/AtomicParsley-debuginfo/setup.hint \
${BASEURL}/AtomicParsley/setup.hint


# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/AtomicParsley/AtomicParsley-0.9.6-1-src.tar.xz \
${BASEURL}/AtomicParsley/AtomicParsley-0.9.6-1.tar.xz \
${BASEURL}/AtomicParsley/AtomicParsley-debuginfo/AtomicParsley-debuginfo-0.9.6-1.tar.xz 
\

${BASEURL}/AtomicParsley/AtomicParsley-debuginfo/setup.hint \
${BASEURL}/AtomicParsley/setup.hint


The package name has been capitalised to reflect the name of the 
executable and to mirror the Fedora package name. Debian and Ubuntu both 
use the lowercase 'atomicparsley' for the package name, but keep the 
executable as 'AtomicParsley'. Personally, I prefer the Fedora 
convention, but I'm happy to change this if there's precedent elsewhere.


I couldn't decide on which category to use in the 'setup.ini' file - 
'Utils' seemed a bit broad, so I settled on 'Audio'. I'm not entirely 
convinced it fits in that category either, so I'll gladly change the 
category if anyone has a strong opinion.


Finally, I've been asked in the past to provide man pages for 
executables in my packages. AtomicParsley doesn't come with a man page, 
so I've generated one using help2man(1). I'm tempted to drop the man 
page though - even the Debian build comes without a man page these days [2].


Cheers,

Dave.

[1] http://pkgs.org/search/AtomicParsley
[2] https://packages.debian.org/wheezy/i386/atomicparsley/filelist

Re: [ITP] mp3info-0.8.5a

[David Stacey]

On 29/05/14 18:26, Yaakov (Cygwin/X) wrote:
Sorry; our policy is to not include MP3 software in the distribution, 
so unfortunately this package cannot be accepted.


Could you possibly elaborate on this please, as I wasn't aware of this 
policy. I presume that it's something like licence issues (not free as 
in freedom) or the risk of patent violation surrounding MP3.


I ask because a little while ago I managed to put a typo in a tag of a 
number of MP4 files, and corrected these by building AtomicParsley [1] 
for Cygwin. I had intended to offer it here, in case someone else found 
it useful. If AtomicParsley falls under the same policy then that's 
fine; I'll strike it off my list of things to do.


Thanks in advance for clarifying,

Dave.

[1] http://atomicparsley.sourceforge.net/

Re: 64-bit: Missing perl modules

[David Stacey]

On 07/04/14 19:54, Reini Urban wrote:

The new 5.18.2 package will be unified for 32bit and 64bit, yes.

perl_vendor will probably stay as is, as it is the easiest for the
user and the maintainer.


Thank you for your reply. I'm pleased that there is a way forward to get 
these perl modules into 64-bit Cygwin, and I look forward to seeing 
'perl_vendor' in our 64-bit land.


Thanks again,

Dave.

Re: 64-bit: Missing perl modules

[David Stacey]

On 06/04/14 17:38, Achim Gratz wrote:

David Stacey writes:

Thank you for your reply. Yes, I was aware of that discussion. I'm not
talking about breaking up 'perl_vendor' for 32-bit Cygwin (although
IMHO that would be a good thing in the long term). I'd just like to
see the perl modules I mentioned adding to 64-bit Cygwin - and I'm
happy to maintain those packages myself if no-one else want to claim
ownership.

I don't see why it should be a good idea to have different packaging for
the two architectures, so I still think this issue needs to be decided.


Agreed. Hopefully the different collections of perl modules that are 
available in the two architectures can be unified with the next perl 
release.



Anyway, here's what I have:


Yes, those are more or less identical to the packages that I prepared - 
I could have done with those links a few days ago :-) It's rather nice 
(albeit inefficient) to have two people trying to do the same thing - so 
often in open source programmes no-one has the time! You've obviously 
put some thought and effort into this, so I'm happy to step back and let 
you (or Reini) to maintain these perl modules. The important thing is 
that they end up in 64-bit Cygwin at some point.


Thankfully, cygport makes most perl modules absurdly easy to maintain. 
So if you need someone to adopt a few if and when 'perl_vendor' gets 
split up then please let me know.


Dave.

Re: 64-bit: Missing perl modules

[David Stacey]

On 06/04/14 07:32, Achim Gratz wrote:

David Stacey writes:

Reini: I am aware that you maintain these modules in the 32-bit
distribution through the 'perl_vendor' package. I don't want to tread
on any toes, and I don't know what plans you have for
'perl_vendor'.

You might want to check the archives for an earlier discussion about
perl_vendor.

https://sourceware.org/ml/cygwin-apps/2012-08/msg6.html


Thank you for your reply. Yes, I was aware of that discussion. I'm not 
talking about breaking up 'perl_vendor' for 32-bit Cygwin (although IMHO 
that would be a good thing in the long term). I'd just like to see the 
perl modules I mentioned adding to 64-bit Cygwin - and I'm happy to 
maintain those packages myself if no-one else want to claim ownership.


Dave.

64-bit: Missing perl modules

[David Stacey]

32-bit Cygwin has a 'perl_vendor' package, which contains a number of 
perl modules that are not present in 64-bit Cygwin. Specifically, I am 
interested in the following perl modules:


Devel::Symdump
Pod::Coverage
Test::Pod
Test::Pod::Coverage

These are all available in the 'perl_vendor' package in 32-bit Cygwin, 
but missing from 64-bit.


Reini: I am aware that you maintain these modules in the 32-bit 
distribution through the 'perl_vendor' package. I don't want to tread on 
any toes, and I don't know what plans you have for 'perl_vendor'. 
However, I would like to see these modules in 64-bit Cygwin, and would 
be happy to maintain them myself if you would prefer not to do so.


Please let me know how you would like to proceed. If you were happy for 
me to maintain these perl modules then I can send an ITP for four 
separate packages. These would be in 64-bit Cygwin only (unless 
'perl_vendor' was to become obsolete). Obviously, I would be equally 
happy for you to provide a 64-bit 'perl_vendor' if you thought that was 
the right thing to do.


Cheers,

Dave.

Re: [RFC] cygport: arch-specific workdir

[David Stacey]

On 27/03/14 18:50, Yaakov (Cygwin/X) wrote:

Actually, that is experimental code (based on a request from another
cygport user) that was accidentally shipped when I had to reroll the
source tarball for compatibility with F20/UnversionedDocDirs. Would
people like to see this done always, never, or only when cross-building?


There hasn't been much comment on this.  Since it would be a visible 
change for package maintainers, I would appreciate more of a 
consensus.  Are there any objections to making the workdir always 
arch-specific (IOW name-ver-rel.arch)?


I wrapped Cygport some time ago to give me a little extra functionality 
- for instance, for each package I maintain, it polls the project web 
page daily and does some regexp to see if a new version of the package 
had been released. If so, a new .cygport file is made and Cygport 
invoked to build, test and package the application.


So any change to Cygport would give me a little maintenance, but I could 
probably cope with a directory rename! Besides, some maintenance on my 
builder is a bit overdue: the tool is still uploading binaries to my 
Dropbox account and preparing [RFU] e-mails :-)


Dave.

Re: [ITP] onc-rpc-headers-20140129-1

[David Stacey]

On 03/02/14 11:23, Pavel Fedin wrote:

  Hello!


Thanks, but... you missed to include links to your package files.

  Huh... That's the main question... What if i have no server at my disposal ?


Presumably you could find some public cloud with free storage space - I 
use Dropbox, but I'm sure there are plenty of others.



Btw., did you already see the web site explaining how to upload your
packages, once they are approved?
https://sourceware.org/cygwin-apps/package-upload.html  

  Yes. I'll need to generate and post my SSH key.
  BTW, does this mean that there are no automatic build server, and packages 
are just delivered as they are?


There was some discussion a while ago about setting up a build server, 
but nothing as yet. You build the packages yourself, and then upload 
binaries and source using the instructions in the link above. But that's 
for when your package has been given a 'GTG' (i.e. Good To Go). You need 
to put the binaries and source on a public-facing web server. Then reply 
to this list with a 'wget' line to download the package.


By way of an example, here's the last one I submitted:
http://cygwin.com/ml/cygwin-apps/2013-09/msg00222.html

Hope this helps,

Dave.

Re: Struggling to upload

[David Stacey]

On 12/11/13 05:31, Christopher Faylor wrote:

On Mon, Nov 11, 2013 at 10:50:00PM +, David Stacey wrote:

>I am attempting to upload perl-Text-CSV_XS-1.02-1 for both x86 and
>x86_64 architectures. I have uploaded the files into my home directory,
>and created '~/x86/!ready' and '~/x86_64/!ready' files. I see that the
>two '!ready' files have disappeared, but the new package is still in my
>home directory and is not visible onftp.cygwin.com.
>
>Please could you tell me what I have done wrong!

The software responsible for moving packages into the cygwin release area
only recognizes your packages as listed in:

http://cygwin.com/cygwin-pkg-maint

Unfortunately, the files you uploaded don't match the case of the
package in that file (perl-Text-CSV_XS vs. perl-text-csv_xs).  I've
just made 'upset' do a case insensitive match so try creating !ready
files again and see if they are then eventually moved.


Thanks - that fixed the problem.

BTW, I took a quick look through the cygwin-pkg-maint page, just to make 
sure that all of my packages were listed correctly. I spotted one 
mistake: please could you change 'doxywizard' to 'doxygen-doxywizard', 
as this is a sub-package of doxygen.


Many thanks once again for fixing the upload problem,

Dave.

Struggling to upload

[David Stacey]

I am attempting to upload perl-Text-CSV_XS-1.02-1 for both x86 and 
x86_64 architectures. I have uploaded the files into my home directory, 
and created '~/x86/!ready' and '~/x86_64/!ready' files. I see that the 
two '!ready' files have disappeared, but the new package is still in my 
home directory and is not visible on ftp.cygwin.com.


Please could you tell me what I have done wrong!

Many thanks in advance,

Dave.