Christopher Faylor | 31 Jul 23:40 2014

Withdrawing from the project

As I mentioned in the cygwin mailing list: I'm withdrawing from the
project.

I'm sending a separate note here with information about the cygwin-apps
part of this decision.

The upset perl script lives in ~cygwin/setup.  This is also a git
repository.  When you push to it, it updates the active version of upset
so be careful.  The companion Makefile which runs upset is also in this
repository/directory.

Scripts for keeping cygwin alive:

/sourceware/infra/bin/check-cygwin-mirrors
  Keeps the mirror list alive, creates the mirrors web page, and mirrors
  list file.  Check cygwin-admin crontab file for how it is run.  Someone
  should change the crontab to have it send email to them.  It used to
  notify me and I temporarily just changed it to sourcemaster@...
/sourceware/infra/bin/cygssh
  Adds a new user when fed "SSH key for upload access" mail.
  I've been running this script as root.  I don't remember why
  now.  Presumably it can be run as the just-created cygwin-admin
  user.  If this actually does need root you'll need to coordinate with
  overseers.

If I missed something look in /sourceware/infra/bin or in the
cygwin-admin crontab.

I'd be happy to receive well wishes or answer questions about my
decision in private email (me period cgf period cx) but please don't
(Continue reading)

Tony Kelman | 26 Jul 10:00 2014
Picon

[ITA] p7zip

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 cygport to 
build in 64 bit Cygwin. I'm willing to adopt the package, if someone can 
guide me through the rest of the process.

Let me know if I'm doing this right. Package files are uploaded here:
https://ci.appveyor.com/api/buildjobs/1cxy8w15aq971cyr/artifacts/p7zip-9.20.1-1.x86_64/dist/p7zip/p7zip-9.20.1-1.tar.xz
https://ci.appveyor.com/api/buildjobs/1cxy8w15aq971cyr/artifacts/p7zip-9.20.1-1.x86_64/dist/p7zip/p7zip-9.20.1-1-src.tar.xz
https://ci.appveyor.com/api/buildjobs/1cxy8w15aq971cyr/artifacts/p7zip-9.20.1-1.x86_64/dist/p7zip/setup.hint

I put the source up in a GitHub repository so you can see the two small 
tweaks I had to make: https://github.com/tkelman/cygwin-p7zip/commits/master
One required repackaging the upstream source tarball to fix line endings on 
a man file (so a patch would apply correctly), the other was to switch to a 
different makefile fragment to use a C version of a CRC routine instead of 
an architecture-dependent assembly version. There's a 64 bit assembly 
version of the same routine included in the source, but I could never get it 
to work reliably. I reported the problem upstream and never got a response: 
https://sourceforge.net/p/p7zip/support-requests/6/#2150

Let me know if any comments or anything else I need to do.

-Tony

P.S: For fun and to see if it would work, I used the AppVeyor CI service to 
build this. You can see the log here 
(Continue reading)

Yaakov Selkowitz | 22 Jul 18:12 2014

man-db: cache handling

Chris,

There are a few issues with the current man-db setup:

1) the cache is not strictly necessary for operation of man(1);

2) mandb -c is quite slow with a large number of manpages (~20min on my
system)

3) generating the cache only during man-db postinstall doesn't help for
manpages updated or added between man-db releases.

Therefore, we need to discuss further how to best handle the man-db
cache.  In the meantime, to help avoid user complaints, could you ship a
new release without the postinstall/preremove?

Yaakov

Achim Gratz | 18 Jul 06:39 2014
Picon

[ATTN maintainer] mined


The mined directory for both architectures contain temporary files that
apparently sftp has left there (they have the suffix SftpXFR.<PID> I
think).  These should be removed, but maybe the transfer script that
moves the files from the upload area could be extended to ignore or
delete such files so they never get distributed to the mirrors.

Regards,
Achim.
--

-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Christian Franke | 14 Jul 19:55 2014
Picon

ruby-rake-10.0.4-1: minor bug in rake.1.gz

Uncompressing the rake man page results in an error message:

$ cygcheck -f /usr/share/man/man1/rake.1.gz
ruby-rake-10.0.4-1

$ gzip -t /usr/share/man/man1/rake.1.gz
gzip: /usr/share/man/man1/rake.1.gz: unexpected end of file

This does not affect the "man rake" command. The uncompressed data is 
complete.

There is only a bogus '\n' at the end of the .gz file:

$ od -t x1 rake.1.gz
...
0002520 bf df c8 48 f4 e4 0a 00 00 0a
.......... ----CRC---- ---SIZE----

$ head -c -1 rake.1.gz | gzip -t

Probably an upstream issue. The rake.1.gz file is also included in the 
source package.

Regards,
Christian

Dave Kilroy | 9 Jul 22:08 2014

Missing enscript dependency

Hi all,

Just tried to use enscript for the first time in a while, and noticed 
that I no longer have an lpr...

Given that `enscript foo.txt` prints to the default printer, it seems 
that enscript is missing a dependency on cygutils-extra.

Thanks,

Dave.

Andrew Schulman | 8 Jul 03:14 2014
Picon

cygport upload command?

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 step.  Maintainers still have to go
through the procedure at
https://sourceware.org/cygwin-apps/package-upload.html.  Although it's
easier than the old manual upload process, it's still a little tedious and
error-prone.

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.

If you don't have the time or interest to add an upload command yourself,
would you consider a patch?  I've spent some time looking through cygport
code, and I might have time to give it a try, or maybe someone else would.

Andrew

Mark Hessling | 3 Jul 23:58 2014

SSH key for upload access

Name: Mark Hessling
Package: regina-rexx
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "2048-bit RSA, converted by mark <at> Windows7-64bit from OpenSSH"
AAAAB3NzaC1yc2EAAAADAQABAAABAQCns1wj8gQNs/lmzMaqhPAyFAcCLFIm1Cqfkf7o5E
yGAoMAVEMTnK3A1M0s1iGUhuX5k2r3EGPdLfsocfTRyw0+Ok5aj64sZVJc1/kaKkXw866M
KTOhxlGlbilepL2y7I0BrzUcMlcA+hGjyo//5019aOBFrlV9NoglADl4GJc9RWNMe/GkLe
W1kgOLZCufB8QPwsvE5cTcD4qov5A0P46HC3d1VHEA3cQzJCsNuOUdHIlXeDv/hUVWhRVs
GSaqLoxpC3QRCSn8MVRQ44k56kW6gcSk2ro5YcEgtm5xMGDgbK1akTvC0GW4dnUNA5ElOi
M6ZRWei2SEpT7l8KkYBFf7
---- END SSH2 PUBLIC KEY ----

Jason Tishler | 1 Jul 02:57 2014
Picon

Re: [SECURITY] python, python3

Yaakov,

On Tue, Jun 24, 2014 at 11:38:35AM -0500, Yaakov Selkowitz wrote:
> On 2014-06-24 09:42, Yaakov Selkowitz wrote:
> >A security vulnerability (CVE-2014-4616) has been announced in python
> >and python3 builtin _json modules.  Patches have been committed
> >upstream; could we get the latest 2.7.7 and 3.2.5 point releases with
> >these patches added?
> >
> >http://bugs.python.org/issue21529
> >https://bugzilla.redhat.com/show_bug.cgi?id=1112285
> 
> Your previous message stated that you were set up for 64bit
> building. Any chance you could do this soon?

I will be AFK for most of July, so I won't be able to look into this
until August.

Sorry,
Jason

Achim Gratz | 29 Jun 20:14 2014
Picon

[ATTN maintainer] rcs


I've developed a patch for the infamous and two-year-old rcs bug that
destroys data, based on the analysis by Peter Wagemans and an earlier
demonstration script by Don Hatch.  The patch has been sent upstream,
but there was no reaction for the last week:

http://article.gmane.org/gmane.comp.version-control.rcs.bugs/2772

I have compiled test packages for both architectures including this
patch.

# The first line sets up shell variable wget, to be used by all later lines
# simply paste into the shell from here
--8<---------------cut here---------------start------------->8---
wget="wget -rxnH http://cygwin.stromeko.net/x86_64/release/"
$wget/rcs/rcs-5.9.2-1-src.tar.xz
$wget/rcs/rcs-5.9.2-1.tar.xz
$wget/rcs/setup.hint
$wget/rcs/rcs-debuginfo/rcs-debuginfo-5.9.2-1.tar.xz
$wget/rcs/rcs-debuginfo/setup.hint
--8<---------------cut here---------------end--------------->8---

# The first line sets up shell variable wget, to be used by all later lines
# simply paste into the shell from here
--8<---------------cut here---------------start------------->8---
wget="wget -rxnH http://cygwin.stromeko.net/x86/release/"
$wget/rcs/rcs-5.9.2-1-src.tar.xz
$wget/rcs/rcs-5.9.2-1.tar.xz
$wget/rcs/setup.hint
$wget/rcs/rcs-debuginfo/rcs-debuginfo-5.9.2-1.tar.xz
(Continue reading)

DJ Sylvester | 26 Jun 22:56 2014
Picon

tmux-1.9a2 ctrl+b not working

I searched Google.
I looked at sourceforge tickets http://sourceforge.net/p/tmux/tickets/
I've read this Cygwin tmux announcement:
https://cygwin.com/ml/cygwin-apps/2014-06/msg00018.html
I've reinstalled tmux with cygwin-x86 installer.

I've had no luck.

ctrl+b "command" is not working for me.

I'm running a default mintty as installed by cygwin-x86 on Win-7 with a
few aliases defined, nothing else. My.tmux.conf file is empty.

To reproduce:
1. start tmux
2. ctrl+b % (outputs 5u)
3. ctrl+b " (no outputs, does nothing)
4. ctrl+b c (no outputs, does nothing)

No commands are working. Not sure what to try next.
Thanks.


Gmane