| 1 |
Mick wrote: |
| 2 |
> On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote: |
| 3 |
>> Michael Mol wrote: |
| 4 |
>>> Hinnerk van Bruinehsen wrote: |
| 5 |
>>>> On 02.01.2012 18:58, Michael Orlitzky wrote: |
| 6 |
>>>>> On 01/02/12 12:47, Mark Knecht wrote: |
| 7 |
>>>>>> Again, 'equery depends' will tell you if any package locatable |
| 8 |
>>>>>> through the @world hierarchy needs the package. No need to |
| 9 |
>>>>>> uninstall anything to do that level of investigation. |
| 10 |
>>>>>> revdep-rebuild -I is also useful, although more historically than |
| 11 |
>>>>>> now. |
| 12 |
>>>>> |
| 13 |
>>>>> This was essentially Michal Mol's suggestion, and I gave an |
| 14 |
>>>>> example where it would remove something important. |
| 15 |
>>>>> |
| 16 |
>>>>>> Really, the proposal to 'fix --update' doesn't address really |
| 17 |
>>>>>> knowing what your system is running and why. Get to the root of |
| 18 |
>>>>>> that and the --update thing becomes the non-issue that many of us |
| 19 |
>>>>>> think it is. |
| 20 |
>>>>> |
| 21 |
>>>>> This would be a suggestion to travel back in time and document |
| 22 |
>>>>> something that I have no way of knowing now. |
| 23 |
>>>> |
| 24 |
>>>> You could create your own overlay with "meta"-ebuilds, e. g. |
| 25 |
>>>> system-maintenance, customer1, customer2. |
| 26 |
>>>> Inside the ebuilds you define depends on the packages the customer |
| 27 |
>>>> wants. Doing so you could wipe everything except the "meta"-ebuilds |
| 28 |
>>>> from world. When a customer quits you can unmerge his or her |
| 29 |
>>>> "meta"-ebuild and depclean. |
| 30 |
>>>> If you add everything needed to the respective "meta"-ebuild, you'll |
| 31 |
>>>> always be on the safe side. |
| 32 |
>>> |
| 33 |
>>> Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is |
| 34 |
>>> complaining that your signature is unverified. I don't know/understand |
| 35 |
>>> PGP/GPG all that well, but I think this is something you're supposed to |
| 36 |
>>> be able to fix on your end. If that's not the case, let me know, and |
| 37 |
>>> I'll get it fixed on my end. :) |
| 38 |
>>> |
| 39 |
>>> gpg command line and output: |
| 40 |
>>> C:\Program Files (x86)\GNU\GnuPG\gpg.exe |
| 41 |
>>> gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C |
| 42 |
>>> gpg: Can't check signature: public key not found |
| 43 |
>> |
| 44 |
>> Doh...that was supposed to go directly to Hinnerk. "Reply to sender |
| 45 |
>> only" my hind leg... |
| 46 |
> |
| 47 |
> Looks like a recently created gpg key. Assuming the owner has uploaded it to |
| 48 |
> a public key server, it seems likely that it has not propagated across the |
| 49 |
> public servers yet and your enigmail plugin alerts you about it. |
| 50 |
|
| 51 |
Found most of the problem; Enigmail defaulted to an empty "automatically |
| 52 |
download keys for signature vereification from the following keyserver" |
| 53 |
field. Fixed that, and things started working a little better. (Herr Van |
| 54 |
Bruinehsen's key doesn't seem to have propagated, yes, but now yours |
| 55 |
works fine. :) ) |
Archives