Militantly FREE software support.
Militantly FREE software support.
NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
Etch-backports and gpg problemsI am running Etch and I want to install the alpine package from I also want to verify the downloaded files. I followed the instructions on the backports instruction page: ---------------------------------------- If you are using *etch* and you want apt to verify the downloaded gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C or wget -O - http://backports.org/debian/archive.key | apt-key add - ---------------------------------------- but after executing the second option (or the second line of the first option) I get the following messages: ---------------------------------------- gpg: no writable keyring found: eof ---------------------------------------- This occurs whether I run this as a normal user, or with sudo. What am I doing wrong? If I then try to run 'aptitude update' I get the following: ---------------------------------------- mns@xander:~$ sudo aptitude update Ign http://www.debian-multimedia.org etch/main Packages/DiffIndex ---------------------------------------- Can someone help me get this sorted out, please? -- -- Bookmark/Search this post with: 
|
• Debian Weekly News - Essential reading for any Debian fan. • Documentation - Debian's own authoritative documentation, including installation docs. • FAQ - Got questions about Debian GNU/Linux? • From Windows to Debian - Tips for converting from Windows to Debian GNU/Linux • Package of the Day. • Security - Security information and alerts! • Bug System - Bug tracking and instructions on reporting bugs. • CD Images - Where/how to get Debian GNU/Linux CD images. • Mailing List Subscription - Dozens of Debian-specific support mailing lists! • Mailing List Archives - Searchable archives of Debian's mailing lists. • Free Software Guidelines - Learn Debian's idea of what "free" software really is. • Package Listings - A very valuable tool: searchable, integrated with bug reports. • Apt-Get Sources - Sources for *.debs which are not official Debian packages. • Backports - Unofficial new software packages that have been "back-ported" to work with the Debian stable/official release. • Developer's Corner - Info about the people behind Debian, policies, and how to package *.deb files.
Etch-backports and gpg problems (SOLVED)
Marc Shapiro wrote:
> I followed the instructions on the backports instruction page:
>
> ----------------------------------------
>
> If you are using *etch* and you want apt to verify the downloaded
> backports you can import backports.org archive’s key into apt:
>
> gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C
> gpg --export | apt-key add -
>
> or
>
> wget -O - http://backports.org/debian/archive.key | apt-key add -
>
> ----------------------------------------
>
>
> but after executing the second option (or the second line of the first
> option) I get the following messages:
>
> ----------------------------------------
>
>
> gpg: no writable keyring found: eof
> gpg: error reading `-': general error
> gpg: import from `-' failed: general error
>
> ----------------------------------------
>
>
> This occurs whether I run this as a normal user, or with sudo. What
> am I doing wrong?
>
If I had run as root, it probably would have worked, but I used sudo.
This only runs the first command as root (I believe), so the command
'apt-key add - ' was run as a normal user and did not like that. Using
sudo on that command, as well, ran without errors.
Alpine is now installed and aptitude gives me no errors.
--
Marc Shapiro
--
Etch-backports and gpg problems (SOLVED)
On 9/23/07, Marc Shapiro wrote:
> If I had run as root, it probably would have worked, but I used sudo.
> This only runs the first command as root (I believe), so the command
> 'apt-key add - ' was run as a normal user and did not like that. Using
It might be worth mentioning that "sudo" doesn't work across pipes:
For instance:
sudo command_1 | command_2
The first command will be run as root, but the second will be run with
normal user permissions. You can probably get around that by enclosing
the entire pipechain in quotes, but there's sometimes when just
entering su for the command and exiting su when finished is easier.
>
--
Etch-backports and gpg problems (SOLVED)
David Fox wrote:
>
> It might be worth mentioning that "sudo" doesn't work across pipes:
>
> For instance:
>
> sudo command_1 | command_2
>
> The first command will be run as root, but the second will be run with
> normal user permissions. You can probably get around that by enclosing
> the entire pipechain in quotes, but there's sometimes when just
> entering su for the command and exiting su when finished is easier.
>
>>
hmmm... How about
sudo command_1 | sudo command_2
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
--
Etch-backports and gpg problems (SOLVED)
Kamaraju S Kusumanchi wrote:
> David Fox wrote:
>
>> It might be worth mentioning that "sudo" doesn't work across pipes:
>>
>> For instance:
>>
>> sudo command_1 | command_2
>>
>> The first command will be run as root, but the second will be run with
>> normal user permissions. You can probably get around that by enclosing
>> the entire pipechain in quotes, but there's sometimes when just
>> entering su for the command and exiting su when finished is easier.
>>
>>
>
> hmmm... How about
>
> sudo command_1 | sudo command_2
>
>
That's exactly the way I did it. Worked like a charm.
--
Marc Shapiro
--
Etch-backports and gpg problems (SOLVED)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/24/07 21:44, Marc Shapiro wrote:
> Kamaraju S Kusumanchi wrote:
>> David Fox wrote:
>>
>>> It might be worth mentioning that "sudo" doesn't work across pipes:
>>>
>>> For instance:
>>>
>>> sudo command_1 | command_2
>>>
>>> The first command will be run as root, but the second will be run with
>>> normal user permissions. You can probably get around that by enclosing
>>> the entire pipechain in quotes, but there's sometimes when just
>>> entering su for the command and exiting su when finished is easier.
>>>
>>>
>>
>> hmmm... How about
>>
>> sudo command_1 | sudo command_2
>>
>>
> That's exactly the way I did it. Worked like a charm.
What about:
sudo (command_1 | command_2)
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG+Q8IS9HxQb37XmcRAuZ2AKDC/UmOaIjXhxO91YyXP1YQGA6CNgCgyFqi
aHfoYyJi61SPlXS7UMbqL6A=
=oxZK
-----END PGP SIGNATURE-----
--
Etch-backports and gpg problems (SOLVED)
On Tue, Sep 25, 2007 at 08:37:12AM -0500, Ron Johnson was heard to say:
> -----BEGIN PGP SIGNED MESSAGE-----
> What about:
> sudo (command_1 | command_2)
Won't work -- the ()s are shell metacharacters, and sudo knows
nothing about them. What you would need to do this with just one
sudo is something like:
sudo sh -c "command_1 | command_2"
with appropriate wariness towards quoting gremlins.
Daniel
--