Re: [ITA/ITP] lots of perl distributions

2015-03-09 Thread Achim Gratz
Achim Gratz writes:
> The upload was extremely slow and I've had the connection drop a few
> times.  Does sourceware throttle connections?  At the moment I can't
> even get a directory listing via sshfs anymore, although lftp still
> seems to cope just fine.

It seems I crossed a threshold with the number of directories in my
release areas… :-(

--8<---cut here---start->8---
getdir[0]
[00032] OPENDIR
  [00032] HANDLE   14bytes (185ms)
[00033] READDIR
[00034] READDIR
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 5064, received 4464 bytes, in 2.8 seconds
Bytes per second: sent 1799.7, received 1586.5
debug1: Exit status -1
remote host has disconnected
executing  <-X> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-2> 
 <-s> 
--8<---cut here---end--->8---

Is there someone who can check what's going on on the server side here?
If not I'll have to switch to using lftp for the upload, but that gives
me a lot less transparency about what is going on and so increases the
chances of doing something wrong.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Re: [ITA/ITP] lots of perl distributions

2015-03-09 Thread Achim Gratz
Achim Gratz writes:
> Yaakov Selkowitz writes:
>> upset does indeed live up to its name in such a case, so we need to
>> rearrange directories on sourceware to match the new layout.  I have
>> done so for perl-LWP, so please proceed.
>
> Thank you very much.  I'll do the upload later today.

The upload was extremely slow and I've had the connection drop a few
times.  Does sourceware throttle connections?  At the moment I can't
even get a directory listing via sshfs anymore, although lftp still
seems to cope just fine.  The upload appears to have finished, but I
want to check everything again.  I'll stop for today and try again
tomorrow.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]

2015-03-09 Thread Corinna Vinschen
On Mar  7 08:14, Andrew Schulman wrote:
> > 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 some gold stars that I
> overlooked, please let me know.

Hmm, that should have been a pink plush hippo rather than two goldstars...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpgQpjpQxyvO.pgp
Description: PGP signature


Re: [RFC] cygport: split debuginfo packages

2015-03-09 Thread Jon TURNEY

On 01/03/2015 17:54, Jon TURNEY wrote:

On 27/02/2015 06:27, Yaakov Selkowitz wrote:

On Mon, 2015-02-23 at 12:14 +, Jon TURNEY wrote:

On 07/07/2012 14:10, Jon TURNEY wrote:

I was going to suggest the use of objcopy --compress-debug-sections,
but it
appears that does nothing for PE/COFF files at the moment [1] :-(

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=14067


That bug has been fixed for a while, so how about the attached?

This appears to reduce the disk space used by .dbg files to about 1/3 of
the size, so seems worthwhile.


Have you tested that the resulting split debuginfo work properly with
gdb?


It's hardly a comprehensive test, but I did try this:

$ objdump -j ".zdebug_info" -s /usr/lib/debug/usr/bin/XWin.exe.dbg | head

/usr/lib/debug/usr/bin/XWin.exe.dbg: file format pei-x86-64


I should have tried this on x86.  There seems to be a good chance that 
this will result in broken debug information on x86.


See binutils bug #18087 [1] for details.

Perhaps this should be reverted unless or until fixed in binutils.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=18087