** Description changed: - Binary package hint: dput + Nature of problem: I am experiencing sftp uploads to ppa.launchpad.net reliably failing to terminate. The dput process appears to be waiting for the ssh (sftp) subprocess to terminate, but it never does. When killed, the upload has actually been successful, and is accepted by Launchpad. - ProblemType: Bug - DistroRelease: Ubuntu 10.10 - Package: dput 0.9.6.1ubuntu1 - ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4 - Uname: Linux 2.6.35-22-generic x86_64 - Architecture: amd64 - Date: Wed Oct 13 00:57:07 2010 - EcryptfsInUse: Yes - PackageArchitecture: all - ProcEnviron: - LC_COLLATE=C - PATH=(custom, user) - LANG=en_GB.utf8 - SHELL=/bin/bash - SourcePackage: dput + Reason for SRUing: + + Launchpad is trying to promote SFTP uploads as the better way to upload + packages, so that it can know who did an upload even if the upload is + unsigned or wrongly signed, but SFTP uploads currently do not work. + + How addressed: + + Leakage of subprocess stdout/stdin filehandles, which caused the + subprocess to never exit, which caused the parent process to wait + forever for it to do so, has been fixed. + + Minimal patch: + + Please see diff in this MP: https://code.launchpad.net/~maxb/bzr/2.2 + -close-ssh-subprocess-socket/+merge/40493 + + TEST CASE: + Attempt to dput any source package to ppa.launchpad.net via SFTP. If the dput process exits successfully, this is a success. If the bug is present, the dput process hangs waiting for a child ssh process to exit, but it never does. + + To do this: + + 1) Configure dput to use sftp. In ~/.dput.cf, add: + [ppa] + fqdn = ppa.launchpad.net + method = sftp + incoming = ~%(ppa)s/ubuntu + login = your-lp-id + + 2) Get a debian source package, it doesn't matter what. e.g. use `apt- + get source hello`. Build it, so you have a valid signed *_source.changes + file. + + 3) dput ppa:not-a-valid-ppa-we-just-want-to-see-if-uploading-works + hello_2.5-1_source.changes + + + Regression potential: Very slim, it's a shallow and well understood bug, with small diff to fix. + + MicroReleaseException: bzr has a MRE, so rather than a targetted backport, an upstream micro release will be used, additionally providing fixes for: + + Don't crash when --take-other or --take-this is called for a text + conflict. LP: #646961 + + Make 'bzr commit' in a checkout propagate new tags to the master. + LP: #603395 + + + I will need a sponsored upload. I hope to have this occur by a sponsor using 'bzr builddeb' from lp:~maxb/ubuntu/maverick/bzr/sru - I will provide a .dsc and .debian.tar.gz if that's not acceptable. + + + -------- STOP PRESS -------- + + This SRU may not happen like this. I've just discovered our + MicroReleaseException is broken. We cannot run the testsuite during + package build, because bzr is in main, but python-testtools is in + universe.
-- dput sftp upload hangs after all files successfully uploaded https://bugs.launchpad.net/bugs/659590 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
