*** This bug is a duplicate of bug 407779 ***
https://bugs.launchpad.net/bugs/407779
Crap, my bad. I didn't search hard enough.
--
add-apt-repository doesn't have a man page, nor a useful --help
https://bugs.launchpad.net/bugs/494792
You received this bug notification because you are a
Work-around for at least the proxy issue:
After you run add-apt-repository and it hangs, it's already set up the repo. I
did let it sit for awhile and it will eventually time out, but it's several
minutes at least.
So, if you cancel out and run 'sudo apt-get update'
Apt-get will complain that
Public bug reported:
There doesn't appear to be a man page, and --help only gives the decidedly
unhelpful:
$ add-apt-repository --help
Usage: add-apt-repository [options]
Options:
-h, --help show this help message and exit
** Affects: software-properties (Ubuntu)
Importance: Undecided
It looks like add-apt-repository doesn't seem to set the http_proxy
variable for GPG, so if you're behind a proxy the keyserver is always
'down'. The process hangs and the only signal it seems to respond to is
-9 (C-\).
--
add-apt-repository insists on downloading GPG key even if keyserver is
The -proposed package, 2.22.1-1ubuntu1, appears to have fixed the issue
for me. My config is a Hardy 8.04-release installed on a PNY USB Flash
Drive with a swap and root partition.
As a matter of correctness (but not really in the scope of this big),
should the device that holds the root
Problem still exists in Hardy 8.04-Release. Sigh. Note that this is a
basic LDAP server, with no SSL/TLS or password required to access the
server. I really like Ubuntu, but this seems like Enterprise Computing
101...
RHEL5/CentOS5 has a patch in their SRPM named 'better-pam-integration'
The patch above didn't go smoothly, and I can't justify working more on
it during work time. :)
But I've found a workaround:
If you add 'auth sufficient pam_ldap.so' to the BEGINNING on
/etc/pam.d/gnome-screensaver, gnome-screensaver unlocks properly for LDAP
users. BUT, there's an odd effect
@Stewart, nyamap: This seems to be the solution, thanks a ton! GDM must
get confused when the root device is classified by hal to be removable.
Perhaps the solution is to add some logic to HAL to force the root
device to be non-removable. It doesn't make much sense to be able to
remove /
