It seems you've re-invented something that David Rothenberger has
implemented before in a slightly different way:
http://thread.gmane.org/gmane.os.cygwin.applications/26034
It's also integrated in my patched-up version of cygport here:
git://repo.or.cz/cygport/rpm-style.git
FWIW,
I have a package (socat) where I need to set the curr: and test: fields in
setup.hint. I got tired of adding them to the autogenerated setup.hint files
after every build, so I wrote a patch for cygport to support specifying them in
the cygport file. For example, setting
CURR=1.7.3.0-2
Any thoughts on a better regex or on keeping compatibility with other
systems?
Right, OK. See the attached revised patch, which uses
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:.{44}
to detect the key fingerprint. The left side is the same as now, for pre-6.8
systems, which use MD5
Is the key fingerprint posted anywhere on cygwin.com or sourceware.org?
I can't
find it. If not, would someone mind adding it to the Uploading Packages
to
cygwin.com page
(https://sourceware.org/cygwin-apps/package-upload.html), so
people can verify it?
Good idea.
On Sun, 2015-05-24 at 12:32 -0400, Andrew Schulman wrote:
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256
I show the SFTP key fingerprint for cygwin.com as
SHA256:MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM
Can anyone please confirm that?
Is the key fingerprint posted anywhere on cygwin.com or sourceware.org? I can't
find it. If not, would someone mind adding it to the Uploading Packages to
From a quick peek at the source, you should make this change in
src/Makefile.am
-libstunnel_la_LDFLAGS = -avoid-version
+libstunnel_la_LDFLAGS = -avoid-version -no-undefined
Right - thanks. Yep, that takes care of it.
and then hope that libstunnel has no undefined symbols that need to
The libtool command should almost always include -no-undefined, so you
should probably add that.
OK, thanks. So, uh... could you suggest how I would add an option to the
libtool command? Sorry, I'm just not strong on autotools. Thanks, Andrew
In stunnel 5.17, the build of libstunnel.la fails with can't build shared
library unless -no-undefined is specified:
/bin/sh ../libtool --tag=CC --mode=link gcc -Wl,-no-undefined
-fdebug-prefix-map=/home/andrex/dev/cygwin/stunnel/stunnel-5.17-1.x86_64/build=/usr/src/debug/stunnel-5.17-1
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256:lvRrjAXmEhzDp5kQqzelsei8s5hXJ+zLaqJ2yiGXmYc
This breaks the current
On Apr 3 13:12, D. Boland wrote:
I noticed that the package is orphaned. I 'd like to adopt it.
Sure, adopting orphaned packages is super.
Gold star awarded: http://cygwin.com/goldstars/#DB
On Apr 23 14:21, Dr. Volker Zell wrote:
Marco Atzeri writes:
On 4/23/2015 1:53 PM, Dr. Volker Zell wrote:
Hi
I would like to adopt and maintain the orphaned 'xclip' package.
already your
https://cygwin.com/cygwin-pkg-maint
I
On Fri, 2015-05-15 at 23:06 +0200, Achim Gratz wrote:
Mosh has been orphaned by Reini Urban and the setup.hint in 32bit is
currently having a wrong dependency. I'm using mosh and would like to
take over maintenance. Since there was no intervening upstream release,
I've simply rebuilt
On Sat, 2015-05-16 at 10:56 +0200, Marco Atzeri wrote:
I am uploading the dependencies of singular now and testing Yue's last
monolithic proposal. If it passes the test as expected I will also
upload both archs during weekend.
Wonderful! Thank you very much for helping with this.
On Mon, 2015-05-18 at 17:41 -0400, Andrew Schulman wrote:
On Mar 5 20:54, Achim Gratz wrote:
In order to reap the fruits of Ken Brown's work on clisp and its
dependencies (which seem to have escaped the attention of the plush
hippo hordes so far)
What? That's
On Mar 13 14:29, Jon TURNEY wrote:
As invited [1], I shall adopt the cygwin-doc package.
That's definitely a pink plush hippo for you. I made you maintainer in
cygwin-pkg-maint.
Awarded! http://cygwin.com/goldstars/#JTy
On Mar 5 20:54, Achim Gratz wrote:
In order to reap the fruits of Ken Brown's work on clisp and its
dependencies (which seem to have escaped the attention of the plush
hippo hordes so far)
What? That's inexcusable. Andrew, one plush hippo for Ken, please.
OK, sure. But I'm having
A security issue has been noted with lftp:
https://bugzilla.redhat.com/show_bug.cgi?id=1180209
This is the patch for 4.6.1:
http://pkgs.fedoraproject.org/cgit/lftp.git/plain/lftp-4.6.1-auto-confirm.patch
Thanks, I wasn't aware of that. New release coming out shortly.
A security issue has been noted with lftp:
https://bugzilla.redhat.com/show_bug.cgi?id=1180209
This is the patch for 4.6.1:
http://pkgs.fedoraproject.org/cgit/lftp.git/plain/lftp-4.6.1-auto-confirm.patch
Thanks, I wasn't aware of that. New release coming out shortly.
lftp
Should I get anything for taking the orphaned
grep/gperf/bison/diffutils/gzip when cgf left? (A single gold star is
plenty for me; that plush hippo is above and beyond the level of effort
it took :)
For sure: https://cygwin.com/goldstars/#EB
Sorry for the oversight. If anyone else is due
On Mar 4 19:23, Achim Gratz wrote:
Corinna Vinschen writes:
On Mar 3 15:59, Warren Young wrote:
On Mar 3, 2015, at 1:25 PM, Corinna Vinschen
corinna-cygwin-rdbxbdvo6bxqt0dzr+alfa-xmd5yjdbdmrexy1tmh2...@public.gmane.org
wrote:
On Mar 3 13:23, Warren Young wrote:
On
On Thu, 2015-02-12 at 08:06 +0100, Marco Atzeri wrote:
I built and packaged the last stable version of less.
wget -r -np -nH --cut-dirs=0 \
http://matzeri.altervista.org/x86_64/less/index.html
wget -r -np -nH --cut-dirs=0 \
http://matzeri.altervista.org/x86/less/index.html
I
On Wed, 2015-02-18 at 14:28 +, David Stacey wrote:
# 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 \
On Tue, 2015-02-17 at 15:54 -0500, Ken Brown wrote:
The x86 build is the same as Reini's build of 2.4.0-2, except for (a) a
tweak to allow it to build with the current gcc and (b) a minor
packaging change: The package provides some example C/C++ files in
/usr/share/doc/fcgi/examples,
On Mon, 2015-02-16 at 16:37 -0500, Ken Brown wrote:
This builds easily on both arches, using essentially the same cygport
file as Yaakov used for icu-51.2-1 on x86_64. I tested it by rebuilding
the TeX Live binaries against libicu54.
GTG. Please proceed, and thanks for adopting. I
On Feb 18 20:56, Achim Gratz wrote:
I've cygported groff and want to maintain it. The current packaging did
not have some files with perl dependencies and the X11 tools were not
present.
BANG! You're maintainer.
Gold star awarded: http://cygwin.com/goldstars/#AG
ploticus Andrew Schulman
This package needs to be updated and I've tried a few times to rebuild
it, but
the build always fails and so far I haven't been able to solve it. I'm
not
actively using it any more anyway, so maybe it's time
On 2/12/2015 11:42 PM, Yaakov Selkowitz wrote:
I have created an upload branch in cygport git based on master with
Andrew's upload work for further testing.
I'm still undecided on $arch/!ready vs. $arch/release/$package/!ready.
Thoughts?
$arch/release/$package/!ready
should avoid
I have created an upload branch in cygport git based on master with
Andrew's upload work for further testing.
FWIW, I've been using it to upload my packages since the last update on Jan. 17,
and before that too, with no problems.
I always keep my ssh keys loaded in a running ssh-agent, so I've
orpieAndrew Schulman
OK. I just rebuilt orpie, and now it depends on libncursesw10. Is that the
right successor to libncurses10? If so, I'll upload the new build.
ploticus Andrew Schulman
This package needs
On Wed, 2015-02-11 at 11:28 -0500, Andrew Schulman wrote:
orpieAndrew Schulman
OK. I just rebuilt orpie, and now it depends on libncursesw10. Is that the
right successor to libncurses10? If so, I'll upload the new build.
Yes, please.
Done
On Feb 4 12:45, Tony Kelman wrote:
Bill promised several time to update cmake, but it seems clear to
me that is has no the time to take care of it.
It will be better to officially declare the package orphan so another
volunteer can take it.
Happy to adopt it.
Super, thanks a
Dear all
I would like to package ssh-pageant and propose it for inclusion in
Cygwin. The small tool acts like an ssh-agent, but instead of storing
its own keys, it is connecting to the PuTTY Pageant tool. This way the
very useful Pageant tool can be used from Cygwin and no separate
I, for one, welcome our new clisp overlord!
ALL HAIL THE CLISP OVERLORD
After much deliberation, I have decide to put my packages up for
adoption. I have not had enough free time to properly maintain my
packages for quite some time. Unfortunately, this is not going to
change for the foreseeable future.
No worries, hopefully you're busy with good things.
If SSH_KEY is set (in the environment, or in ~/.cygport.conf), then cygport
will
load that key into an ssh-agent if necessary.
Minor nit: SSH_KEY as env var is so generic and easily confused with
the variables set by ssh-agent. Wouldn't something with CYGPORT in its
name be better?
On Jan 17 11:16, Achim Gratz wrote:
Corinna Vinschen writes:
What would be most helpful is to get a piece of documentation for us
maintainers how to use the new _autorebase facility, sent with a fat
HEADSUP subject, and which we can ideally add to setup.html.
The _autorebase
You're right, this isn't pretty. :-( Any progress since then?
OK, here's what I've worked out.
If SSH_KEY is set (in the environment, or in ~/.cygport.conf), then cygport will
load that key into an ssh-agent if necessary.
* If no ssh-agent is running, cygport will start one and load the
On Jan 16 09:08, Marco Atzeri wrote:
On 1/15/2015 2:03 PM, Marco Atzeri wrote:
On 1/14/2015 3:13 PM, Corinna Vinschen wrote:
Hi folks,
it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
the 32 bit distro. Fortunately they were never in the 64 bit distro.
- Look if ssh-agent is running (SSH_AGENT_PID non-empty?)
- If not, start ssh-agent and ssh-add. This asks for the passphrase,
if any.
- run sftp
- If the script started ssh-agent, run eval $(ssh-agent -k)
I just played with this a bit and it turned out that you must be
It's vexing that it's so hard to find a solution to such a simple problem:
prompt the user for a password if and only if one is needed.
Indeed. Here's another crazy idea.
- Look if ssh-agent is running (SSH_AGENT_PID non-empty?)
- If not, start ssh-agent and ssh-add. This asks for the
You're right, this isn't pretty. :-( Any progress since then?
Well, I had a good idea: set up a shared (ControlMaster) ssh connection first,
in order to get the authentication out of the way, then have the sftp batch step
use the shared connection.
Unfortunately it seems that that idea isn't
lftp sftp://cygwin:@cygwin.com
Sorry, should be
lftp sftp://cyg...@cygwin.com
After you clone cygport in Cygwin, do you get the same result as below?
$ file autogen.sh
autogen.sh: Bourne-Again shell script, ASCII text executable, with CRLF
line terminators
No CRLF. Either you're using a Windows git, or maybe you're trying to
clone into a text mount.
Thank
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
/tmp git clone
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/cygport
Cloning into 'cygport'...
remote: Counting objects: 9806, done.
remote: Compressing
On 2014-12-30 09:43, Andrew Schulman wrote:
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
Are you sure you're using a Cygwin git?
Yes.
/tmp which git
/usr/bin/git
/tmp git --version
git version 2.1.1
I
On 2014-12-30 09:43, Andrew Schulman wrote:
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
Are you sure you're using a Cygwin git?
So is Cygwin git normally supposed to take care of the DOS line endings
Here's what I have at the moment based on your branch as of a few weeks
ago. However, with password-protected SSH keys, the password prompt
isn't handled properly. Any ideas?
OK, I've looked into this. It can be done, but the only solution I can see
so far is ugly. Here's the deal:
--8---cut here---start-8---
I love the little ASCII art scissors.
The point of having an upload command
is to relieve packagers of the tedium and likelihood of getting it wrong
when they have to remember where to connect to and which commands to run to
put what files where. How much nicer to just run cygport up and let
cygport handle it.
It then
On Dec 8 20:40, Andrew Schulman wrote:
Here's what I have at the moment based on your branch as of a few weeks
ago. However, with password-protected SSH keys, the password prompt
isn't handled properly. Any ideas?
Re password prompts: I see the problem. It's because I
Andrew Schulman writes:
upload
Adds the upload command: upload finished packages to cygwin.com.
I don't think the !ready files should be created by cygport, at all.
Yaakov will decide, but I disagree. The point of having an upload command
is to relieve packagers of the tedium
* The current implementation puts the !ready file into a package-specific
directory, e.g. /x86_64/screen, instead of /x86_64.
Should say: /x86_64/release/screen, instead of /x86_64/release.
Here's what I have at the moment based on your branch as of a few weeks
ago. However, with password-protected SSH keys, the password prompt
isn't handled properly. Any ideas?
Re password prompts: I see the problem. It's because I echo the lftp
script to stdout, and pipe it into lftp
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
BTW I see that you commented out the line:
echo rm -f !ready || echo -n
in the lftp script in __pkg_upload(). That line is there to prevent a race
condition if the maintainer has already made one upload, then later starts
to make another one, at the same time that upset starts to
Here's what I have at the moment based on your branch as of a few weeks
ago. However, with password-protected SSH keys, the password prompt
isn't handled properly. Any ideas?
OK. Looks good.
Re password prompts: I see the problem. It's because I echo the lftp
script to stdout, and pipe
On Nov 19 12:38, Achim Gratz wrote:
Corinna Vinschen writes:
In any case, this is mainly about putting the mechanism in place or
rather to specify it. Making it usable would require support from
cygport and upset/genini.
Not upset, it seems. IIUC the stratumification can firmly
I'd like to have some more input here. Maintainers, if you have any
input to this, please follow up.
I'm sorry - I didn't follow the previous discussion and am having trouble
following this. Could you please restate what's being proposed?
It starts here:
Andrew Schulman writes:
I'm sorry - I didn't follow the previous discussion and am having trouble
following this. Could you please restate what's being proposed?
TL;DR: Everyone who has been happy with the current way of how install
and postinstall works has nothing to fear or do
I want to maintain sitecopy for Cygwin. sitecopy is in Debian:
https://packages.debian.org/stable/utils/sitecopy
setup.hint:
category: Net Web
requires: libintl8 libneon27
sdesc: Manage a WWW site via FTP, SFTP, DAV or HTTP
ldesc: Sitecopy is for copying locally stored websites to remote
Neat, but does it work as intended?
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
//calimero.vinschen.de/cygwin 194676832 48674368 146002464 26% /cygwin
//calimero.vinschen.de/ext 191068816 29408432 161660384 16% /ext
C:
Another abandoned package. Builds with only a little fiddling. Last
update upstream was in 1996.
x86:
http://home.comcast.net/~andrex2/cygwin/x86/time/setup.hint
http://home.comcast.net/~andrex2/cygwin/x86/time/time-1.7-4.tar.xz
I want to maintain discus for Cygwin. discus is in Debian:
https://packages.debian.org/unstable/utils/discus
setup.hint:
category: Utils
requires: python
sdesc: Pretty version of df(1) command
ldesc: Discus aims to make df prettier, with features such as color,
graphs, and smart formatting of
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
On 2014-10-19 09:13, Andrew Schulman wrote:
I've published several improvements to cygport on Github. Each improvement
is in its own branch:
upload
Adds the upload command: upload finished packages to cygwin.com.
I definitely want to add this feature. However, the implementation
Thanks for taking a look.
On 2014-10-19 09:13, Andrew Schulman wrote:
I've published several improvements to cygport on Github. Each improvement
is in its own branch:
upload
Adds the upload command: upload finished packages to cygwin.com.
I definitely want to add this feature
OK. Can you please suggest a package with subpackages that I can easily
build to see what's going on in that case?
Nevermind, I'm using arpack.
I've published several improvements to cygport on Github. Each improvement
is in its own branch:
upload
Adds the upload command: upload finished packages to cygwin.com.
fish
Creates fish scripts in /etc/profile.d/*.fish.
src_prep_fini_hook
Adds support for the src_prep_fini_hook() hook
It seems you meant to send these to announce
Yes, sorry about that.
Hi Andrew,
On Oct 13 11:38, Corinna Vinschen wrote:
On Oct 13 04:33, Andrew Schulman wrote:
I'd like to adopt the fish package. The package seems to be abandoned. A
new release is out upstream with multiple security fixes, but the Cygwin
package hasn't been updated. Emails
I see that bc is orphaned. Since fish depends on it, I'd like to adopt it.
I checked the cygport script, and it builds fine from source.
bc hasn't been updated since 2006, so I'm not expecting to make any new
releases any time soon.
Andrew
bc hasn't been updated since 2006, so I'm not expecting to make any new
releases any time soon.
The 32 bit version is older, lacking some patches and lacking a cygport
based source archive. Would you mind terribly to create and upload a
bc-1.06.95-1 32 bit package along the lines of the
The bc package has been updated in the Cygwin distribution.
This is a minor update, a Cygwin point release, that includes the latest
patches from upstream, latest meaning mostly 3 years ago or more.
bc is an arbitrary precision numeric processing language. Syntax is similar
to C, but differs in
The fish package has been updated in the Cygwin distribution.
New in this release:
* Multiple security fixes. See the release notes for version 2.1.1 at
http://fishshell.com/release_notes.html .
* Add system directories to PATH. fish now runs correctly as the user's
default login shell.
*
Minor nit: This should be `cygport upload' to be in line with the
other cygport commands. Alternatively, cygport could introduce a
two-letter abbreviation scheme, for instance:
cygport download- cygport dl or (rcs-like) co
cygport prep- cygport pr
I'd like to adopt the fish package. The package seems to be abandoned. A
new release is out upstream with multiple security fixes, but the Cygwin
package hasn't been updated. Emails to the maintainer have bounced, and he
hasn't answered recent discussions on the cygwin list about the need to
One comment regarding the new config.fish file - can you make the cd
$HOME dependent upon the CHERE_INVOKING variable being unset? That way
chere will work for those who set it up for fish. See /etc/profile for
the bash equivalent.
Sure, that will go in revision -3.
On 2014-07-07 20:14, Andrew Schulman wrote:
Yaakov, would you consider adding an 'upload' command to cygport, that
would handle the uploading details? That would take away the last bit of
manual work in a routine package update.
I'm a bit busy at the moment, but it sounds like a good
On 2014-08-17 03:46, Marco Atzeri wrote:
On 17/08/2014 09:56, Yaakov Selkowitz wrote:
On Sun, 2014-08-17 at 09:44 +0200, Marco Atzeri wrote:
On 17/08/2014 08:47, Yaakov Selkowitz wrote:
Why no debuginfo?
no idea.
the build system is a bit basic, pre-autoconf age,
Then you need
I'm not sure what the process is for adopting somebody else's package;
the Submitting a new package instructions don't seem to apply since
it's not a new package, but I don't yet have upload rights to just go
ahead and do it.
Adam, you are now listed as maintainer in cygwin-pkg-maint,
On 2014-08-11 17:03, Marco Atzeri wrote:
attached 2 files.
The first is basically what should be the new cygwin-pkg-maint
that cover all the active package in both 32bit and 64 bit.
This was great, thank you. After rearranging the release areas, I was
able to get a more reliable list
Thanks all for the feedback and help. Sorry for showing up at a bad time.
Note: You should perhaps remove the keepdir that preserves the
/usr/lib/p7zip/Codecs directory. This drops a zero-size .keep-p7zip
file in there that elicits a warning from p7zip since it isn't a codec.
On the
Yes, there's ARCH, ARCH_i686, and ARCH_x86_64. See
/usr/share/doc/cygport/manual.html.
Thanks, that's a great resource. I'm used to long-form docs being
online somewhere rather than already installed along with the package.
I'm a bit unclear what needs to happen next, despite reading
On the topic of cygport, is there a variable that indicates whether --32 or
--64 was specified?
Yes, there's ARCH, ARCH_i686, and ARCH_x86_64. See
/usr/share/doc/cygport/manual.html.
Hi,
I noticed that all of Chuck Wilson's packages are now listed as orphaned.
I'm particularly interested in getting one of them, p7zip, uploaded to the
64-bit distribution. I sent a few messages to the main list in March
discussing what I needed to change in order to get the existing
Using cygport, I think that packaging has become quite easy now. At least,
once the cygport script is built and working, updating a package to a new
release is as easy as updating the version number in the cygport script,
then running 'cygport ... download all'.
Except for one thing: the upload
On Jun 24 22:49, David Stacey wrote:
xloadimage is an X11 image viewer and processor. The Cygwin package was
orphaned by Jari earlier this month [1].
Thanks for taking over. Looks good, please upload.
Thanks,
Corinna
Gold star awarded: http://cygwin.com/goldstars/#DSt
Adopting rsync (orpahaned, Lapo Luchini):
https://cygwin.com/cygwin-pkg-maint
I have new 3.1.0 ready for both x86 and x86_64.
Let me know when I can upload.
Jari
Gold star awarded: http://cygwin.com/goldstars/#JAa
On Jun 15 12:57, Jari Aalto wrote:
Adopting tnef (orpahaned, Jonathan C. Allen):
https://cygwin.com/cygwin-pkg-maint
I have new 1.4.9 ready for both x86 and x86_64.
Let me know when I can upload.
Please go ahead with this one and rsync.
Thanks a lot for taking over!
On 2014-06-09 13:11, Achim Gratz wrote:
Since Chuck went AWOL (it's really distressing that nobody heard
anything from him since February) I've packaged a corrected version of
run with cygport. I won't be able to do much in the way of further
development for run. So if anybody else
I'd like to maintain sng for Cygwin. sng is a markup language and
compiler/decompiler for PNG images.
sng is in Debian (https://packages.debian.org/wheezy/sng). It also used
to be in Cygwin, until it was obsoleted last year because it depended on
libpng12. Thanks to Yaakov for pointing me to
On May 20 04:40, Andrew Schulman wrote:
I'd like to maintain sng for Cygwin. sng is a markup language and
compiler/decompiler for PNG images.
sng is in Debian (https://packages.debian.org/wheezy/sng). It also used
to be in Cygwin, until it was obsoleted last year because it depended
On 13/05/2014 20:32, Andrew Schulman wrote:
Attached is a patch which moves the old method one and two to an archive
page, and continues the boffo packaging example into the section for the
cygport method.
Other stuff left to do:
- Change to link to the new upload process page
I'd like to adopt the pinfo package, since I use it. I have a new build of
the latest version, 0.6.10, ready for x86 and x86_64, with a new cygport
build script.
I'm not sure if there's anything else I need to do. If there's no
objection, I think I can just add pinfo to my !packages file in the
Attached is a patch which moves the old method one and two to an archive
page, and continues the boffo packaging example into the section for the
cygport method.
Other stuff left to do:
- Change to link to the new upload process page
- Correct paths on the package server from release/ to
On Tue, May 13, 2014 at 03:03:19PM -0400, Andrew Schulman wrote:
I'd like to adopt the pinfo package, since I use it. I have a new build of
the latest version, 0.6.10, ready for x86 and x86_64, with a new cygport
build script.
I'm not sure if there's anything else I need to do. If there's
I'm running cygport 0.15.0-1 in x86_64. I thought cygport was always
supposed to create .xz packages now, but for some reason for me it's
creating .gz packages.
I have the xz package installed, and /usr/bin/xz works. My cygport file
is below. What am I missing?
Thanks, Andrew.
NAME=socat
I'm running cygport 0.15.0-1 in x86_64. I thought cygport was always
supposed to create .xz packages now, but for some reason for me it's
creating .gz packages.
Sorry - not true. Please disregard. Andrew
I reported this problem a few months ago. Now I have a screenshot to
show it: http://postimg.org/image/e5uzokbn9/
My last setup run was about a week ago. I just started
setup-x86_64.exe, and OOTB it wants to install 9 new packages. I didn't
select them, and they're not required - setup just
201 - 300 of 609 matches
Mail list logo
