From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48353 invoked by alias); 5 Nov 2015 21:08:17 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 48337 invoked by uid 89); 5 Nov 2015 21:08:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 05 Nov 2015 21:08:14 +0000 Received: by wmll128 with SMTP id l128so21577770wml.0 for ; Thu, 05 Nov 2015 13:08:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=s0Coq7ZeqJvLsHEpDRqtI7L0Fc0rMWYpmlbhmlMhXlk=; b=b77X4sbxLLCa5O0jfUc06bWJwr7chY3+0RA4g6VTKXns6zVv4CJAKxa/GUd6kVAR4k PYIcoy8kZ/QLUj1J5jByx9sFU0iy1JpSDytJ3EDNKAt4FRwg7gUJ8HWzBOawZw4p9dtm Sm/72/cEICDo4jnt3BBwPA5eZmcYfhfUFjA6iKcYIXw2DOpHqls2kJCW9o0Fn7GehARt pAzgw8ARILbbQ3YCYVPscn2VOxJmtoEgdseB3MDViLiAZATTTPI7j86wvDJc1bXGScqn D/DXEmvk+1eUbW5XTT8gwyvc6kX+LnZmiBlGsB+O2YyJzQbWVFq4q2t9ywl6EF/HywSJ z5qA== X-Gm-Message-State: ALoCoQmUkpDG0aq82k+cWc+RTHiJ/1FfYB3tfDEp3fk3KJwM5nsZi9I86mO+s+2VFxsMtG62GBpw X-Received: by 10.28.88.143 with SMTP id m137mr5957646wmb.13.1446757691727; Thu, 05 Nov 2015 13:08:11 -0800 (PST) Received: from dinwoodie.org ([2001:ba8:0:1c0::9:1]) by smtp.gmail.com with ESMTPSA id 79sm10262568wmf.13.2015.11.05.13.08.10 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 13:08:11 -0800 (PST) Date: Thu, 05 Nov 2015 21:08:00 -0000 From: Adam Dinwoodie To: cygwin-apps@cygwin.com Subject: Cygport uploading different files to different arch directorys for noarch packages Message-ID: <20151105210809.GT14466@dinwoodie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00028.txt.bz2 I'm seeing what seems to be some very odd behaviour from Cygport when uploading noarch packages: Cygport uploads all the packages for the 64-bit architecture, but only the main and source packages for 32-bit architecture. Mostly I'm looking to know whether other people experience the same behaviour when using Cygport to upload noarch packages -- the behaviour I'm seeing is entirely reproducible on my system. I've done some digging, and I'm utterly baffled, so I'm going to post this here in case anyone else has any cunning theories; arguably this is into the realms of an lftp/cygport/bash bug, so if folk want me to take it to the main list, I'm happy to do that too. Here's what I'm seeing (having commented out the !ready line in pkg_upload.cygpart to allow testing, although I've checked both ways and that doesn't make a difference): $ cygport fzf.cygport upload >>> Uploading fzf-0.10.8-1.noarch >>> Running lftp sftp://cygwin:@cygwin.com cd ok, cwd=/x86/release Transferring file `fzf-0.10.8-1-src.tar.xz' Transferring file `fzf-0.10.8-1.tar.xz' Transferring file `setup.hint' cd ok, cwd=/x86_64/release New: 3 files, 0 symlinks 116628 bytes transferred in 1 second (84.4 KiB/s) Transferring file `fzf-0.10.8-1-src.tar.xz' Transferring file `fzf-0.10.8-1.tar.xz' Transferring file `setup.hint' Making directory `fzf-bash' Transferring file `fzf-bash/fzf-bash-0.10.8-1.tar.xz' Transferring file `fzf-bash/setup.hint' Making directory `fzf-bash-completion' Transferring file `fzf-bash-completion/fzf-bash-completion-0.10.8-1.tar.xz' Transferring file `fzf-bash-completion/setup.hint' Making directory `fzf-fish' Transferring file `fzf-fish/fzf-fish-0.10.8-1.tar.xz' Transferring file `fzf-fish/setup.hint' Making directory `fzf-vim' Transferring file `fzf-vim/fzf-vim-0.10.8-1.tar.xz' Transferring file `fzf-vim/setup.hint' Making directory `fzf-zsh' Transferring file `fzf-zsh/fzf-zsh-0.10.8-1.tar.xz' Transferring file `fzf-zsh/setup.hint' Making directory `fzf-zsh-completion' Transferring file `fzf-zsh-completion/fzf-zsh-completion-0.10.8-1.tar.xz' Transferring file `fzf-zsh-completion/setup.hint' Total: 6 directories, 15 files, 0 symlinks New: 15 files, 0 symlinks 129612 bytes transferred in 8 seconds (15.3 KiB/s) Upload complete. Note only three files were uploaded before the cd to /x86_64/release. I've looked at the cygport code, and I can see no way this could happen -- the code for uploading to x86 and x86_64 is the same code on a loop -- and yet it's happening reliably for me. By way of further testing, I hacked the Cygport code to dump the lftp commands to file, then emulated the lftp command from my Bash shell: $ cat upload_commands set cmd:fail-exit on set cmd:interactive on set net:max-retries 1 open sftp://cygwin:@cygwin.com cd /x86/release rm -f fzf/!ready || echo -n mirror -v -eR fzf cd /x86_64/release rm -f fzf/!ready || echo -n mirror -v -eR fzf $ lftp -f <(cat upload_commands) cd ok, cwd=/x86/release Making directory `fzf-bash' Transferring file `fzf-bash/fzf-bash-0.10.8-1.tar.xz' Transferring file `fzf-bash/setup.hint' Making directory `fzf-bash-completion' Transferring file `fzf-bash-completion/fzf-bash-completion-0.10.8-1.tar.xz' Transferring file `fzf-bash-completion/setup.hint' Making directory `fzf-fish' Transferring file `fzf-fish/fzf-fish-0.10.8-1.tar.xz' Transferring file `fzf-fish/setup.hint' Making directory `fzf-vim' Transferring file `fzf-vim/fzf-vim-0.10.8-1.tar.xz' Transferring file `fzf-vim/setup.hint' Making directory `fzf-zsh' Transferring file `fzf-zsh/fzf-zsh-0.10.8-1.tar.xz' Transferring file `fzf-zsh/setup.hint' Making directory `fzf-zsh-completion' Transferring file `fzf-zsh-completion/fzf-zsh-completion-0.10.8-1.tar.xz' Transferring file `fzf-zsh-completion/setup.hint' Total: 6 directories, 15 files, 0 symlinks New: 12 files, 0 symlinks 12984 bytes transferred in 7 seconds (1.8 KiB/s) cd ok, cwd=/x86_64/release Total: 6 directories, 15 files, 0 symlinks So everything works fine there: it correctly finishes the x86 upload I started in Cygport and does nothing for the already completed x86_64 upload. For further testing, I hacked Cygport up some more to write that upload_commands file out, then immediately read from it using the same command as above. This produced the bugged behaviour again, which implies it's definitely something about the Cygport environment that's causing the odd behaviour. As I say, I'm utterly baffled by this. For now I'll just upload the remaining x86 files manually, but I'd love to know what's going on.