no status update after dput for ppa package
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
I thought I'd take a stab at testing ppa, so I took an old bit of authtool source and banged away at following the instructions in https:/
I've tried again twice (via dput -f), signing with key 0x2C9EBA60 which is registered for nealmcb in launchpad. Still no mail and no build status on the web.
So my first question is "What is the status of my PPA packages?"
In the broader picture, it seems that a goal of PPA is to get more folks involved in packaging, so having better documentation, which includes detailed examples, common error conditions, and fixes would be helpful.
E.g. I heard that packages signed by the "wrong key" are silently thrown away. For PPA that sounds like it will lead to lots of frustration especially for the many newbies.
Can dput somehow confirm that launchpad will provide future status info?
If not, how do people track down these sorts of problems?
Changed in soyuz: | |
importance: | Undecided → Wishlist |
tags: | added: soyuz-upload |
tags: | added: poppy |
Here are some other relevant details.
authtool_ 0.2.2~ppa1_ source. upload:
Successfully uploaded ../authtool_ 0.2.2~ppa1. dsc to ppa.launchpad.net. 0.2.2~ppa1. tar.gz to ppa.launchpad.net. 0.2.2~ppa1_ source. changes to ppa.launchpad.net.
Successfully uploaded ../authtool_
Successfully uploaded ../authtool_
(3 times)
.dput.cf:
[my-ppa]
fqdn = ppa.launchpad.net
incoming = ~nealmcb/ubuntu/
login = anonymous
It would seem that getting dput to provide some sort of tracking id would enable much better status tracking. Perhaps the dput output should indicate the full upload location in its output as a URL like launchpad. net/~nealmcb/ ubuntu/ authtool_ 0.2.2~ppa1. dsc (or whatever)
ftp://ppa.
and that could be cut-and-pasted as input in some launchpad web query to get status?
Or Is ftp just the wrong sort of protocol for this queue injection function?