I'm not sure if there's a better place to put this, so please feel free to
tell me I should report it elsewhere (:
After the recent GitHub fun, I changed from using the GitHub git source to
git://anongit.gentoo.org/repo/sync/gentoo.git, as suggested by some on this
mailing list. I completely
Am Donnerstag, 5. Juli 2018, 23:37:53 CEST schrieb Marc Joliet:
> Am Donnerstag, 5. Juli 2018, 21:22:15 CEST schrieb Grant Edwards:
> [SNIP]
>
> For those still having this problem, see https://bugs.gentoo.org/659914#c9.
>
> In my case I just ran my usual "emerge -uDUva @world", which updated to
On Thursday, 5 July 2018 23:05:51 BST Grant Edwards wrote:
> On 2018-07-05, Grant Edwards wrote:
> > On 2018-07-05, Grant Edwards wrote:
> >> On 2018-07-05, Grant Edwards wrote:
> >>> As of today, I seem to be unable to a an "emerge --sync".
> >>
> >>> The process either hangs forever at the
On 2018-07-05, Grant Edwards wrote:
> On 2018-07-05, Grant Edwards wrote:
>> On 2018-07-05, Grant Edwards wrote:
>>> As of today, I seem to be unable to a an "emerge --sync".
>>>
>>> The process either hangs forever at the "Refreshing keys from keyserver
>>> step:
>>
>> [...]
>>
>>> Or, it
Am Donnerstag, 5. Juli 2018, 21:22:15 CEST schrieb Grant Edwards:
[SNIP]
For those still having this problem, see https://bugs.gentoo.org/659914#c9.
In my case I just ran my usual "emerge -uDUva @world", which updated to the
new app-crypt/openpgp-keys-gentoo-release-20180703 despite the sync
On 2018-07-05, Grant Edwards wrote:
> On 2018-07-05, Grant Edwards wrote:
>> As of today, I seem to be unable to a an "emerge --sync".
>>
>> The process either hangs forever at the "Refreshing keys from keyserver step:
>
> [...]
>
>> Or, it fails because there are no public key to verify a
Grant Edwards wrote:
> On 2018-07-05, Grant Edwards wrote:
>> As of today, I seem to be unable to a an "emerge --sync".
>>
>> The process either hangs forever at the "Refreshing keys from keyserver step:
> [...]
>
>> Or, it fails because there are no public key to verify a manfest:
> For now,
On 2018-07-05, Jalus Bilieyich wrote:
> You just need to use Gentoo's built-in script from gentoolkit.
>
> Just run:
>
> # etc-update
>
> And overwrite the current config file you have (trust me, it's safe).
No help. All that did was update the sshd config file by adding the following:
On 2018-07-05, Grant Edwards wrote:
> As of today, I seem to be unable to a an "emerge --sync".
>
> The process either hangs forever at the "Refreshing keys from keyserver step:
[...]
> Or, it fails because there are no public key to verify a manfest:
For now, I've had to set add
You just need to use Gentoo's built-in script from gentoolkit.
Just run:
# etc-update
And overwrite the current config file you have (trust me, it's safe).
On 7/5/18, Grant Edwards wrote:
> As of today, I seem to be unable to a an "emerge --sync".
>
> The process either hangs forever at the
As of today, I seem to be unable to a an "emerge --sync".
The process either hangs forever at the "Refreshing keys from keyserver step:
# emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
*
On Sun, Jun 10, 2018 at 19:18:25 +, Alan Mackenzie wrote:
> Hello again, Dale.
> On Sun, Jun 10, 2018 at 11:23:14 -0500, Dale wrote:
> > To, OP. I was hoping you found a solution. Maybe you will at some
> > point, You have certainly eliminated a lot of potential causes. I
> > can't
My use case may be slightly different to others who use git or webrsync. I've
always used rsync to keep portage up to date. Since the portage gentoo keys
went out of sync a couple of days ago I ended up like other gentoo users with
a 'chicken and egg' situation. The rsync process would fail
On Wed, 04 Jul 2018 22:57:05 -0400
John Covici wrote:
I got the following when running your command:
gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/
INFO:root:Refreshing keys from keyserver...
INFO:root:Keys refreshed.
To be more specific, I wasn't interested in verifying the
On 2018-07-04, gevisz wrote:
> 2018-07-04 21:00 GMT+03:00 Jack :
>> On 2018.07.04 13:38, gevisz wrote:
>>> I hate using sudo since I have been forced to use it in Ubuntu.
>>
>> I almost never used sudo when I used Ubuntu. I used su or logged in as root
>> when necessary.
>
> It is quite strange
On Wed, Jul 4, 2018 at 1:34 PM Rich Freeman wrote:
>
> I wonder if we can have portage instead do a fetch, then do the
> verification of HEAD, and then if it passes do a checkout. That will
> still leave you with invalid data in the git history, but it won't
> actually be checked out, so at
On 05/07/18 08:54, Adam Carter wrote:
> Does anyone know of a reason why this would happen?
>
>
> Is firefox built with pulseaudio? If so, check the pavucontrol settings
> too (media-sound/pavucontrol)
>
> Perhaps VLC is talking directly to ALSA, but firefox is talking to
>
On Thu, 05 Jul 2018 12:06:53 +0200
Kai Peter wrote:
> On 2018-07-05 09:09, Zoltán Kócsi wrote:
> [...]
> See bug 604802 (https://bugs.gentoo.org/604802).
>
> Workaround: unmerge gperf, merge libpcap, afterwards merge gperf
> again.
>
> For an 'emerge -e @world', temporarily downgrade to
On 2018-07-05 09:09, Zoltán Kócsi wrote:
The */* x86_ ... in the use file and asking emerge to re-build the
libraries is pretty cool for building both 64 and 32 bit libs.
But it has it's problems, it seems.
The library libcap fails to compile with some spectacular errors:
2018-07-05 1:25 GMT+03:00 Mick :
> On Wednesday, 4 July 2018 19:32:33 BST gevisz wrote:
>> 2018-07-04 21:01 GMT+03:00 Mick :
>> > On Wednesday, 4 July 2018 18:57:56 BST gevisz wrote:
>> >> 2018-07-04 11:55 GMT+03:00 Alex Thorne :
>> >> >> I use rsync and get the following for more than a day now;
The */* x86_ ... in the use file and asking emerge to re-build the
libraries is pretty cool for building both 64 and 32 bit libs.
But it has it's problems, it seems.
The library libcap fails to compile with some spectacular errors:
--
x86_64-pc-linux-gnu-gcc -m32
21 matches
Mail list logo
