public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Adam Dinwoodie <adam@dinwoodie.org>
To: cygwin-apps@cygwin.com
Subject: Cygport uploading different files to different arch directorys for noarch packages
Date: Thu, 05 Nov 2015 21:08:00 -0000	[thread overview]
Message-ID: <20151105210809.GT14466@dinwoodie.org> (raw)

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.

             reply	other threads:[~2015-11-05 21:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05 21:08 Adam Dinwoodie [this message]
2015-11-05 22:12 ` Andrew Schulman
2015-11-05 23:25   ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151105210809.GT14466@dinwoodie.org \
    --to=adam@dinwoodie.org \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).