Re: [gentoo-user] Problem with gdbus-codegen

[Alan McKinnon]

On 30/01/2017 01:06, Mick wrote:
> On Sunday 29 Jan 2017 22:10:59 Neil Bothwick wrote:
>> On Sun, 29 Jan 2017 19:17:47 +, Mick wrote:
 Are you running fstrim once in a while like it's recommended?
 Apparently using 'discard' as an option when mounting is no longer
 recommended. On my laptops I use a systemd timer to do this. Before
 that I used anacron (I think it was anacron) which would run missed
 cronjobs.
>>>
>>> This is surprised me ... I just installed Gentoo on a MacBook and the
>>> handbook/wiki said to use discard in fstab ... I'm running two PCs like
>>> this now.  :-/
>>>
>>> Is there a URL somewhere recommending otherwise?
>>
>> man fstrim:
>>
>> Running fstrim  frequently, or even using mount -o discard, might
>> negatively affect the lifetime of poor-quality SSD devices. For most
>> desktop and server systems a sufficient trimming frequency is once a
>> week. Note that not all devices support a queued trim, so each trim
>> command incurs a performance penalty on whatever else might be trying to
>> use the disk at the time.
> 
> Hmm  I better take these discards off fstab then.  Are these weekly trims 
> OK, if the PC is rebooted on a daily basis?
> 

You can deal with trim as if it were a low-impact defrag on Windows. All
trim really does is clean up blocks from deleted files, nuke the
metadata and return the blocks to the unallocated pool.

This is an expensive operation on SSDs which is why they are delayed. In
theory you could even leave the disk untrim'med until you need the space :-)


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

On Monday 30 Jan 2017 10:02:20 I wrote:
> On Sunday 29 Jan 2017 09:59:53 Daniel Frey wrote:
> > As far as monitoring, some vendors have tools for that I believe. They
> > usually do run SMART.
> 
> I've found an off-line testing suite here [1], which I'll have a play
> with.

Oops!

[1] https://github.com/axboe/fio/

-- 
Regards
Peter

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

On Sunday 29 Jan 2017 09:59:53 Daniel Frey wrote:

> As far as monitoring, some vendors have tools for that I believe. They
> usually do run SMART.

I've found an off-line testing suite here [1], which I'll have a play with.

> Are you running fstrim once in a while like it's recommended? Apparently
> using 'discard' as an option when mounting is no longer recommended. On
> my laptops I use a systemd timer to do this. Before that I used anacron
> (I think it was anacron) which would run missed cronjobs.

I thought I had a twice-daily cron job running fstrim, but then I found I've 
been running without it for somewhat over a month. I've now reinstated the 
missing crontab entries and I'll watch for more things going bump in the 
night.

One partition had also grown to 75% occupancy so I've also enlarged that. It 
was the ~/.VirtualBox partition, and boinc creates, uses and discards VMs 
all the time, so it's possible the two problems compounded each other to 
cause my portage damage.

-- 
Regards
Peter

Re: [gentoo-user] Problem with gdbus-codegen

[Daniel Frey]

On 01/29/2017 03:06 PM, Mick wrote:
> On Sunday 29 Jan 2017 22:10:59 Neil Bothwick wrote:
>> On Sun, 29 Jan 2017 19:17:47 +, Mick wrote:
 Are you running fstrim once in a while like it's recommended?
 Apparently using 'discard' as an option when mounting is no longer
 recommended. On my laptops I use a systemd timer to do this. Before
 that I used anacron (I think it was anacron) which would run missed
 cronjobs.
>>>
>>> This is surprised me ... I just installed Gentoo on a MacBook and the
>>> handbook/wiki said to use discard in fstab ... I'm running two PCs like
>>> this now.  :-/
>>>
>>> Is there a URL somewhere recommending otherwise?
>>
>> man fstrim:
>>
>> Running fstrim  frequently, or even using mount -o discard, might
>> negatively affect the lifetime of poor-quality SSD devices. For most
>> desktop and server systems a sufficient trimming frequency is once a
>> week. Note that not all devices support a queued trim, so each trim
>> command incurs a performance penalty on whatever else might be trying to
>> use the disk at the time.
> 
> Hmm  I better take these discards off fstab then.  Are these weekly trims 
> OK, if the PC is rebooted on a daily basis?
> 

Yes, just make sure you use anacron or a systemd timer that will run a
missed job. I remember somewhere once or twice a day was OK as well as
fstrim will complete faster. It is noticable when fstrim is running.

Dan

Re: [gentoo-user] Problem with gdbus-codegen

[Neil Bothwick]

On Sun, 29 Jan 2017 23:06:23 +, Mick wrote:

> > Running fstrim  frequently, or even using mount -o discard, might
> > negatively affect the lifetime of poor-quality SSD devices. For most
> > desktop and server systems a sufficient trimming frequency is once a
> > week. Note that not all devices support a queued trim, so each trim
> > command incurs a performance penalty on whatever else might be trying
> > to use the disk at the time.  
> 
> Hmm  I better take these discards off fstab then.  Are these weekly
> trims OK, if the PC is rebooted on a daily basis?

Weekly seems to be what the man page recommends. You could certainly get
away with less on a lightly used system.


-- 
Neil Bothwick

What do you call a dead bee? - A was.


pgpBtoGNb15Ph.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Problem with gdbus-codegen

[Mick]

On Sunday 29 Jan 2017 22:10:59 Neil Bothwick wrote:
> On Sun, 29 Jan 2017 19:17:47 +, Mick wrote:
> > > Are you running fstrim once in a while like it's recommended?
> > > Apparently using 'discard' as an option when mounting is no longer
> > > recommended. On my laptops I use a systemd timer to do this. Before
> > > that I used anacron (I think it was anacron) which would run missed
> > > cronjobs.
> > 
> > This is surprised me ... I just installed Gentoo on a MacBook and the
> > handbook/wiki said to use discard in fstab ... I'm running two PCs like
> > this now.  :-/
> > 
> > Is there a URL somewhere recommending otherwise?
> 
> man fstrim:
> 
> Running fstrim  frequently, or even using mount -o discard, might
> negatively affect the lifetime of poor-quality SSD devices. For most
> desktop and server systems a sufficient trimming frequency is once a
> week. Note that not all devices support a queued trim, so each trim
> command incurs a performance penalty on whatever else might be trying to
> use the disk at the time.

Hmm  I better take these discards off fstab then.  Are these weekly trims 
OK, if the PC is rebooted on a daily basis?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Problem with gdbus-codegen

[Neil Bothwick]

On Sun, 29 Jan 2017 19:17:47 +, Mick wrote:

> > Are you running fstrim once in a while like it's recommended?
> > Apparently using 'discard' as an option when mounting is no longer
> > recommended. On my laptops I use a systemd timer to do this. Before
> > that I used anacron (I think it was anacron) which would run missed
> > cronjobs.

> This is surprised me ... I just installed Gentoo on a MacBook and the 
> handbook/wiki said to use discard in fstab ... I'm running two PCs like
> this now.  :-/
> 
> Is there a URL somewhere recommending otherwise?

man fstrim:

Running fstrim  frequently, or even using mount -o discard, might
negatively affect the lifetime of poor-quality SSD devices. For most
desktop and server systems a sufficient trimming frequency is once a
week. Note that not all devices support a queued trim, so each trim
command incurs a performance penalty on whatever else might be trying to
use the disk at the time. 


-- 
Neil Bothwick

I am Scooby Doo of Borg- Reware roo re arimorated, Raggy!


pgpXhYoJloZmJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Problem with gdbus-codegen

[Mick]

On Sunday 29 Jan 2017 09:59:53 Daniel Frey wrote:
> On 01/29/2017 02:09 AM, Peter Humphrey wrote:
> >> Do you have a SSD? That sounds like symptoms of a failing SSD to me
> >> (it's happened more than once to me :/)
> > 
> > Yes, nothing but one 256 GB NVMe drive in this box. Is there something
> > like
> > hdparm that will keep an eye on it for me?
> > 
> > I hope it isn't that already: the whole system only dates from last May.
> 
> I used to run an SSD on my home server (running mythtv, among other
> things), until one day I got home and it was misbehaving.
> 
> I couldn't log into the server using ssh, so I logged in on the console.
> Everything appeared to be running but nothing new would load. Tried
> sync'ing to see if I could remerge various packages but got a similar
> weird error and found out half my portage tree was *poof*. On further
> inspection, about 40% of the OS files were gone. No wonder I problems
> logging on.
> 
> This happened twice to me, so I no longer use SSDs on machines I use as
> servers in my home, they're just too unreliable. At least with spinning
> rust you get some warning and can usually do some recovery.

PVR/DVRs use a different specification of drives, which spin at a lower speed 
and remain cooler for long(er) periods of operation.


> As far as monitoring, some vendors have tools for that I believe. They
> usually do run SMART.
> 
> Are you running fstrim once in a while like it's recommended? Apparently
> using 'discard' as an option when mounting is no longer recommended. On
> my laptops I use a systemd timer to do this. Before that I used anacron
> (I think it was anacron) which would run missed cronjobs.
> 
> Dan

This is surprised me ... I just installed Gentoo on a MacBook and the 
handbook/wiki said to use discard in fstab ... I'm running two PCs like this 
now.  :-/

Is there a URL somewhere recommending otherwise?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Problem with gdbus-codegen

[Daniel Frey]

On 01/29/2017 02:09 AM, Peter Humphrey wrote:
>> Do you have a SSD? That sounds like symptoms of a failing SSD to me
>> (it's happened more than once to me :/)
> 
> Yes, nothing but one 256 GB NVMe drive in this box. Is there something like 
> hdparm that will keep an eye on it for me?
> 
> I hope it isn't that already: the whole system only dates from last May.
> 

I used to run an SSD on my home server (running mythtv, among other
things), until one day I got home and it was misbehaving.

I couldn't log into the server using ssh, so I logged in on the console.
Everything appeared to be running but nothing new would load. Tried
sync'ing to see if I could remerge various packages but got a similar
weird error and found out half my portage tree was *poof*. On further
inspection, about 40% of the OS files were gone. No wonder I problems
logging on.

This happened twice to me, so I no longer use SSDs on machines I use as
servers in my home, they're just too unreliable. At least with spinning
rust you get some warning and can usually do some recovery.

As far as monitoring, some vendors have tools for that I believe. They
usually do run SMART.

Are you running fstrim once in a while like it's recommended? Apparently
using 'discard' as an option when mounting is no longer recommended. On
my laptops I use a systemd timer to do this. Before that I used anacron
(I think it was anacron) which would run missed cronjobs.

Dan

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

On Saturday 28 Jan 2017 08:40:04 Daniel Frey wrote:
> On 01/28/2017 03:16 AM, Peter Humphrey wrote:
> > On Thursday 26 Jan 2017 22:42:06 Alan McKinnon wrote:
> >> Somethng has gone wrong with your installation of portage or your copy
> >> of the tree - that "no ebuilds" message is impossible.
> > 
> > Indeed so. So I've now built a fresh system and I'll see how that goes.
> > 
> >> It will probably be a cruel task to track down exactly what is wrong,
> >> my
> >> intuition says something in a local cache somewhere. Might be easiest
> >> just to delete all portage data (*except* /var/db/pkg), download a new
> >> tree tarball and let portage sort itself out
> > 
> > [OT]
> > Recent versions of System Rescue CD have a different web browser, and on
> > my screen it's unusable because any change of style in the text (bold,
> > italic etc. or an embedded link) causes overlapping. So I had to revert
> > to an older version for the installation handbook.
> > [/OT]
> 
> Do you have a SSD? That sounds like symptoms of a failing SSD to me
> (it's happened more than once to me :/)

Yes, nothing but one 256 GB NVMe drive in this box. Is there something like 
hdparm that will keep an eye on it for me?

I hope it isn't that already: the whole system only dates from last May.

-- 
Regards
Peter

Re: [gentoo-user] Problem with gdbus-codegen

[Daniel Frey]

On 01/28/2017 03:16 AM, Peter Humphrey wrote:
> On Thursday 26 Jan 2017 22:42:06 Alan McKinnon wrote:
> 
>> Somethng has gone wrong with your installation of portage or your copy
>> of the tree - that "no ebuilds" message is impossible.
> 
> Indeed so. So I've now built a fresh system and I'll see how that goes.
> 
>> It will probably be a cruel task to track down exactly what is wrong, my
>> intuition says something in a local cache somewhere. Might be easiest
>> just to delete all portage data (*except* /var/db/pkg), download a new
>> tree tarball and let portage sort itself out
> 
> [OT]
> Recent versions of System Rescue CD have a different web browser, and on my 
> screen it's unusable because any change of style in the text (bold, italic 
> etc. or an embedded link) causes overlapping. So I had to revert to an older 
> version for the installation handbook.
> [/OT]
> 

Do you have a SSD? That sounds like symptoms of a failing SSD to me
(it's happened more than once to me :/)

Dan

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

On Thursday 26 Jan 2017 15:08:25 Dale wrote:

> OP.  From my emerge --info:
> 
> sync-uri: rsync://rsync26.us.gentoo.org/gentoo-portage
> 
> That one worked just the other day.  You may want to try it.  Also,
> emerge-webrsync may be a option after trying another mirror.  Also, if
> you change the mirror, you may want to use mirrorselect -r -i or you can
> change it manually.  I'm pretty sure it is changed in gentoo-conf in
> this path:  /etc/portage/repos.conf/.

I switched to git syncing not long ago, so I don't have any say in which 
mirror I use - unless someone can tell me otherwise.

-- 
Regards
Peter

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

On Thursday 26 Jan 2017 22:42:06 Alan McKinnon wrote:

> Somethng has gone wrong with your installation of portage or your copy
> of the tree - that "no ebuilds" message is impossible.

Indeed so. So I've now built a fresh system and I'll see how that goes.

> It will probably be a cruel task to track down exactly what is wrong, my
> intuition says something in a local cache somewhere. Might be easiest
> just to delete all portage data (*except* /var/db/pkg), download a new
> tree tarball and let portage sort itself out

[OT]
Recent versions of System Rescue CD have a different web browser, and on my 
screen it's unusable because any change of style in the text (bold, italic 
etc. or an embedded link) causes overlapping. So I had to revert to an older 
version for the installation handbook.
[/OT]

-- 
Regards
Peter

Re: [gentoo-user] Problem with gdbus-codegen

[Marc Joliet]

On Thursday 26 January 2017 22:42:06 Alan McKinnon wrote:
> On 26/01/2017 17:35, Peter Humphrey wrote:
> > (Sent via webmail while I continue wrestling with KMail...)
> > 
> > Alan McKinnon  wrote :
> >> Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
> >> emerge give a different result?
> > 
> > peak ~ # emerj -1 =gdbus-codegen-2.50.2
> > Calculating dependencies  ... done!
> > 
> > emerge: there are no ebuilds to satisfy "=gdbus-codegen-2.50.2".
> > peak ~ # eix -e gdbus-codegen
> > [I] dev-util/gdbus-codegen
> > 
> >  Available versions:  2.44.1 2.46.2 2.48.2 (~)2.50.0 (~)2.50.1
> >  (~)2.50.2 {PYTHON_TARGETS="python2_7 python3_4 python3_5"} Installed
> >  versions:  2.50.2(18:06:24 10/01/17)(PYTHON_TARGETS="python2_7
> >  python3_4 -python3_5") Homepage:http://www.gtk.org/
> >  Description: GDBus code and documentation generator
> > 
> > Something's screwed up here. I ran eclean-dist this morning and it listed
> > 90-odd packages with versions not in the database, which was not true.
> > Running eix-update again made no difference.
> > 
> > I'm considering building a new system, but amd64 instead of ~amd64. I only
> > set the latter when this was a new box and too many packages needed to be
> > the ~ versions to be manageable otherwise.
> Somethng has gone wrong with your installation of portage or your copy
> of the tree - that "no ebuilds" message is impossible.
> 
> It will probably be a cruel task to track down exactly what is wrong, my
> intuition says something in a local cache somewhere. Might be easiest
> just to delete all portage data (*except* /var/db/pkg), download a new
> tree tarball and let portage sort itself out

No clue if it's related or not, but I thought I'd mention this anyway:

This reminds me of a vaguely similar problem I had this week, though luckily 
it was time-variant: portage refused to update boost-build because it was 
masked, but the reason given was... literally empty.  Immediately retrying it 
on my desktop worked, but on my laptop it took a few retries (*no* changes in-
between) for portage to offer the upgrade. (Actually, for $reasons, I wanted 
to do --fetchonly first, which took a few retries, then do the upgrade proper, 
which took several more tries before the error went away again.)

Naturally, I haven't had any problems since...

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Problem with gdbus-codegen

[Dale]

Mick wrote:
> On Thursday 26 Jan 2017 15:08:25 Dale wrote:
>> That's my thinking as well. I recall not long ago that I caught a bad
>> sync.. It was several days later that I was able to get a good one
>> and even then, it required me to switch to another mirror. I think in
>> my case, someone decided to shut down that mirror but for some
>> reason, only removed some of the files there. Some very obvious
>> packages were missing. I noticed several KDE packages and even some
>> that are in @system missing.
> I recall 12-13 years ago there was a proposal to improve security by
> sync'ing with different mirrors and diffing the output. I seem to
> recall someone had hacked a mirror and interfered with the tree served
> by it. The proposal was not taken up because it would double up the
> load on the mirrors and of course two mirrors may not be in exactly
> the same state at a particular point in time.

I'm not on dial-up anymore but I wouldn't want to have to do that twice
either.  My DSL is not *that* fast.  I've had bad syncs in the past.  It
is rare but it does happen.  Anytime I get something really weird, I try
to check and see what the tree looks like.  One can also scroll back up
and see what all was changed, file wise anyway. 

I recall those discussion and have seen security mentioned since as
well.  While I think it is not likely, it could happen.  Thing is, the
tree is a moving target as you mention.  It never really stops being
changed.  Given the world wide nature of the devs, there is almost
always someone changing something.  To download it twice and compare
would be interesting to see.  Talk about a hat trick.  ;-) 

I suspect that if a hacker wanted to screw things up, they would find a
way.  It doesn't hurt to try and keep it to a minimum tho.  I wish I
could recall what server I was using. 

Dale

:-)  :-) 

Re: [gentoo-user] Problem with gdbus-codegen

[Mick]

On Thursday 26 Jan 2017 15:08:25 Dale wrote:

> That's my thinking as well.  I recall not long ago that I caught a bad
> sync..  It was several days later that I was able to get a good one and
> even then, it required me to switch to another mirror.  I think in my
> case, someone decided to shut down that mirror but for some reason, only
> removed some of the files there.  Some very obvious packages were
> missing.  I noticed several KDE packages and even some that are in
> @system missing.

I recall 12-13 years ago there was a proposal to improve security by sync'ing 
with different mirrors and diffing the output.  I seem to recall someone had 
hacked a mirror and interfered with the tree served by it.  The proposal was 
not taken up because it would double up the load on the mirrors and of course 
two mirrors may not be in exactly the same state at a particular point in 
time.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Problem with gdbus-codegen

[Corbin Bird]

On 01/26/2017 11:15 AM, Peter Humphrey wrote:
> Corbin Bird  wrote :
>
>
>> If you would please, run this command and post the output ( a test in
>> other words ).
>>
>>> emerge -pvt dev-util/gdbus-codegen:0
> It wants to downgrade again, with the same output as I posted last time.
>
A package version / dependency blocker?

This command might ID the culprit.

> equery g dev-util/gdbus-codegen:0

Example results :

>  * dependency graph for dev-util/gdbus-codegen-2.48.2
>  `--  dev-util/gdbus-codegen-2.48.2  amd64
>`--  dev-lang/python-2.7.12  (>=dev-lang/python-2.7.5-r2) amd64  [xml]
>`--  dev-lang/python-3.4.5  (dev-lang/python) amd64  [xml]
>`--  dev-lang/python-3.5.2  (dev-lang/python) ~amd64  [xml]
>`--  dev-lang/python-exec-2.4.4  (>=dev-lang/python-exec-2) amd64 
> [python_targets_python2_7(-)? python_targets_python3_4(-)?
> python_targets_python3_5(-)? -python_single_target_python2_7(-)
> -python_single_target_python3_4(-) -python_single_target_python3_5(-)]
>`--  app-arch/xz-utils-5.2.3  (app-arch/xz-utils) amd64
>`--  dev-libs/glib-2.48.2  (>=dev-libs/glib-2.48.2) amd64
> [ dev-util/gdbus-codegen-2.48.2 stats: packages (7), max depth (1) ]

>  * dependency graph for dev-util/gdbus-codegen-2.50.2
>  `--  dev-util/gdbus-codegen-2.50.2  [~amd64 keyword]
>`--  dev-lang/python-2.7.12  (>=dev-lang/python-2.7.5-r2) amd64  [xml]
>`--  dev-lang/python-3.4.5  (dev-lang/python) amd64  [xml]
>`--  dev-lang/python-3.5.2  (dev-lang/python) ~amd64  [xml]
>`--  dev-lang/python-exec-2.4.4  (>=dev-lang/python-exec-2) amd64 
> [python_targets_python2_7(-)? python_targets_python3_4(-)?
> python_targets_python3_5(-)? -python_single_target_python2_7(-)
> -python_single_target_python3_4(-) -python_single_target_python3_5(-)]
>`--  app-arch/xz-utils-5.2.3  (app-arch/xz-utils) amd64
>`--  dev-libs/glib-2.50.2  (>=dev-libs/glib-2.50.2) [~amd64 keyword]
> [ dev-util/gdbus-codegen-2.50.2 stats: packages (7), max depth (1) ]

I didn't know that the USE flag "xml" was required by
"dev-util/gdbus-codegen" on the "dev-lang/python" packages.

Learned a new approach to determine dependency blockers. Thank You :)

Re: [gentoo-user] Problem with gdbus-codegen

[Dale]

Alan McKinnon wrote:
> On 26/01/2017 17:35, Peter Humphrey wrote:
>> (Sent via webmail while I continue wrestling with KMail...)
>>
>> Alan McKinnon  wrote :
>>
>>> Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
>>> emerge give a different result?
>> peak ~ # emerj -1 =gdbus-codegen-2.50.2
>> Calculating dependencies  ... done!
>>
>> emerge: there are no ebuilds to satisfy "=gdbus-codegen-2.50.2".
>> peak ~ # eix -e gdbus-codegen
>> [I] dev-util/gdbus-codegen
>>  Available versions:  2.44.1 2.46.2 2.48.2 (~)2.50.0 (~)2.50.1 (~)2.50.2 
>> {PYTHON_TARGETS="python2_7 python3_4 python3_5"}
>>  Installed versions:  2.50.2(18:06:24 
>> 10/01/17)(PYTHON_TARGETS="python2_7 python3_4 -python3_5")
>>  Homepage:http://www.gtk.org/
>>  Description: GDBus code and documentation generator
>>
>> Something's screwed up here. I ran eclean-dist this morning and it listed 
>> 90-odd packages with versions not in the database, which was not true. 
>> Running eix-update again made no difference.
>>
>> I'm considering building a new system, but amd64 instead of ~amd64. I only 
>> set the latter when this was a new box and too many packages needed to be 
>> the ~ versions to be manageable otherwise.
>>
>
> Somethng has gone wrong with your installation of portage or your copy
> of the tree - that "no ebuilds" message is impossible.
>
> It will probably be a cruel task to track down exactly what is wrong, my
> intuition says something in a local cache somewhere. Might be easiest
> just to delete all portage data (*except* /var/db/pkg), download a new
> tree tarball and let portage sort itself out
>


That's my thinking as well.  I recall not long ago that I caught a bad
sync..  It was several days later that I was able to get a good one and
even then, it required me to switch to another mirror.  I think in my
case, someone decided to shut down that mirror but for some reason, only
removed some of the files there.  Some very obvious packages were
missing.  I noticed several KDE packages and even some that are in
@system missing. 

OP.  From my emerge --info:

sync-uri: rsync://rsync26.us.gentoo.org/gentoo-portage 

That one worked just the other day.  You may want to try it.  Also,
emerge-webrsync may be a option after trying another mirror.  Also, if
you change the mirror, you may want to use mirrorselect -r -i or you can
change it manually.  I'm pretty sure it is changed in gentoo-conf in
this path:  /etc/portage/repos.conf/. 

Dale

:-)  :-) 

Re: [gentoo-user] Problem with gdbus-codegen

[Alan McKinnon]

On 26/01/2017 17:35, Peter Humphrey wrote:
> (Sent via webmail while I continue wrestling with KMail...)
> 
> Alan McKinnon  wrote :
> 
>> Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
>> emerge give a different result?
> 
> peak ~ # emerj -1 =gdbus-codegen-2.50.2
> Calculating dependencies  ... done!
> 
> emerge: there are no ebuilds to satisfy "=gdbus-codegen-2.50.2".
> peak ~ # eix -e gdbus-codegen
> [I] dev-util/gdbus-codegen
>  Available versions:  2.44.1 2.46.2 2.48.2 (~)2.50.0 (~)2.50.1 (~)2.50.2 
> {PYTHON_TARGETS="python2_7 python3_4 python3_5"}
>  Installed versions:  2.50.2(18:06:24 10/01/17)(PYTHON_TARGETS="python2_7 
> python3_4 -python3_5")
>  Homepage:http://www.gtk.org/
>  Description: GDBus code and documentation generator
> 
> Something's screwed up here. I ran eclean-dist this morning and it listed 
> 90-odd packages with versions not in the database, which was not true. 
> Running eix-update again made no difference.
> 
> I'm considering building a new system, but amd64 instead of ~amd64. I only 
> set the latter when this was a new box and too many packages needed to be the 
> ~ versions to be manageable otherwise.
> 


Somethng has gone wrong with your installation of portage or your copy
of the tree - that "no ebuilds" message is impossible.

It will probably be a cruel task to track down exactly what is wrong, my
intuition says something in a local cache somewhere. Might be easiest
just to delete all portage data (*except* /var/db/pkg), download a new
tree tarball and let portage sort itself out

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Problem with gdbus-codegen

[Neil Bothwick]

On Thu, 26 Jan 2017 17:15:04 +, Peter Humphrey wrote:

> > If you would please, run this command and post the output ( a test in
> > other words ).
> >   
> > > emerge -pvt dev-util/gdbus-codegen:0  
> 
> It wants to downgrade again, with the same output as I posted last time.

The addition of -t should have given a clue as to what wants to downgrade
it. You should also check

grep -r gdbus-codegen /etc/portage


-- 
Neil Bothwick

What do you call a dead bee? - A was.


pgpvq9RAl7Oeh.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

Corbin Bird  wrote :


> If you would please, run this command and post the output ( a test in
> other words ).
> 
> > emerge -pvt dev-util/gdbus-codegen:0

It wants to downgrade again, with the same output as I posted last time.

-- 
Regards,
Peter.

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

Dale  wrote :

> I'd try a fresh sync first.  Maybe something went wrong during the last
> one??  Here is some info from mine:

Yes, that was my first thought, but I've sync'd several times in the last 24 
hours so that isn't it.

> root@fireball / # equery l -p gobject-introspection
>  * Searching for gobject-introspection ...
> [-P-] [  ] dev-libs/gobject-introspection-1.44.0:0
> [-P-] [  ] dev-libs/gobject-introspection-1.46.0:0
> [IP-] [  ] dev-libs/gobject-introspection-1.48.0:0
> [-P-] [ ~] dev-libs/gobject-introspection-1.50.0:0
> root@fireball / # equery l -p gdbus-codegen
>  * Searching for gdbus-codegen ...
> [-P-] [  ] dev-util/gdbus-codegen-2.44.1:0
> [-P-] [  ] dev-util/gdbus-codegen-2.46.2:0
> [IP-] [  ] dev-util/gdbus-codegen-2.48.2:0
> [-P-] [ ~] dev-util/gdbus-codegen-2.50.0:0
> [-P-] [ ~] dev-util/gdbus-codegen-2.50.1:0
> [-P-] [ ~] dev-util/gdbus-codegen-2.50.2:0
> root@fireball / # qlop -s | tail -n 1
> Tue Jan 24 23:58:26 2017 >>> gentoo
> root@fireball / #
> 
> Hope that helps.

Fraid not  :-)

-- 
Regards,
Peter.

Re: [gentoo-user] Problem with gdbus-codegen

[Corbin Bird]

On 01/26/2017 09:35 AM, Peter Humphrey wrote:
> (Sent via webmail while I continue wrestling with KMail...)
>
> Alan McKinnon  wrote :
>
>> Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
>> emerge give a different result?
> peak ~ # emerj -1 =gdbus-codegen-2.50.2
> Calculating dependencies  ... done!
>
> emerge: there are no ebuilds to satisfy "=gdbus-codegen-2.50.2".
> peak ~ # eix -e gdbus-codegen
> [I] dev-util/gdbus-codegen
>  Available versions:  2.44.1 2.46.2 2.48.2 (~)2.50.0 (~)2.50.1 (~)2.50.2 
> {PYTHON_TARGETS="python2_7 python3_4 python3_5"}
>  Installed versions:  2.50.2(18:06:24 10/01/17)(PYTHON_TARGETS="python2_7 
> python3_4 -python3_5")
>  Homepage:http://www.gtk.org/
>  Description: GDBus code and documentation generator
>
> Something's screwed up here. I ran eclean-dist this morning and it listed 
> 90-odd packages with versions not in the database, which was not true. 
> Running eix-update again made no difference.
>
> I'm considering building a new system, but amd64 instead of ~amd64. I only 
> set the latter when this was a new box and too many packages needed to be the 
> ~ versions to be manageable otherwise.
>

If you would please, run this command and post the output ( a test in
other words ).

> emerge -pvt dev-util/gdbus-codegen:0

Re: [gentoo-user] Problem with gdbus-codegen

[Dale]

Peter Humphrey wrote:
> (Sent via webmail while I continue wrestling with KMail...)
>
> Alan McKinnon  wrote :
>
>> Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
>> emerge give a different result?
> peak ~ # emerj -1 =gdbus-codegen-2.50.2
> Calculating dependencies  ... done!
>
> emerge: there are no ebuilds to satisfy "=gdbus-codegen-2.50.2".
> peak ~ # eix -e gdbus-codegen
> [I] dev-util/gdbus-codegen
>  Available versions:  2.44.1 2.46.2 2.48.2 (~)2.50.0 (~)2.50.1 (~)2.50.2 
> {PYTHON_TARGETS="python2_7 python3_4 python3_5"}
>  Installed versions:  2.50.2(18:06:24 10/01/17)(PYTHON_TARGETS="python2_7 
> python3_4 -python3_5")
>  Homepage:http://www.gtk.org/
>  Description: GDBus code and documentation generator
>
> Something's screwed up here. I ran eclean-dist this morning and it listed 
> 90-odd packages with versions not in the database, which was not true. 
> Running eix-update again made no difference.
>
> I'm considering building a new system, but amd64 instead of ~amd64. I only 
> set the latter when this was a new box and too many packages needed to be the 
> ~ versions to be manageable otherwise.
>


I'd try a fresh sync first.  Maybe something went wrong during the last
one??  Here is some info from mine:


root@fireball / # equery l -p gobject-introspection
 * Searching for gobject-introspection ...
[-P-] [  ] dev-libs/gobject-introspection-1.44.0:0
[-P-] [  ] dev-libs/gobject-introspection-1.46.0:0
[IP-] [  ] dev-libs/gobject-introspection-1.48.0:0
[-P-] [ ~] dev-libs/gobject-introspection-1.50.0:0
root@fireball / # equery l -p gdbus-codegen
 * Searching for gdbus-codegen ...
[-P-] [  ] dev-util/gdbus-codegen-2.44.1:0
[-P-] [  ] dev-util/gdbus-codegen-2.46.2:0
[IP-] [  ] dev-util/gdbus-codegen-2.48.2:0
[-P-] [ ~] dev-util/gdbus-codegen-2.50.0:0
[-P-] [ ~] dev-util/gdbus-codegen-2.50.1:0
[-P-] [ ~] dev-util/gdbus-codegen-2.50.2:0
root@fireball / # qlop -s | tail -n 1
Tue Jan 24 23:58:26 2017 >>> gentoo
root@fireball / #

Hope that helps.

Dale

:-)  :-) 

Re: [gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

(Sent via webmail while I continue wrestling with KMail...)

Alan McKinnon  wrote :

> Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
> emerge give a different result?

peak ~ # emerj -1 =gdbus-codegen-2.50.2
Calculating dependencies  ... done!

emerge: there are no ebuilds to satisfy "=gdbus-codegen-2.50.2".
peak ~ # eix -e gdbus-codegen
[I] dev-util/gdbus-codegen
 Available versions:  2.44.1 2.46.2 2.48.2 (~)2.50.0 (~)2.50.1 (~)2.50.2 
{PYTHON_TARGETS="python2_7 python3_4 python3_5"}
 Installed versions:  2.50.2(18:06:24 10/01/17)(PYTHON_TARGETS="python2_7 
python3_4 -python3_5")
 Homepage:http://www.gtk.org/
 Description: GDBus code and documentation generator

Something's screwed up here. I ran eclean-dist this morning and it listed 
90-odd packages with versions not in the database, which was not true. Running 
eix-update again made no difference.

I'm considering building a new system, but amd64 instead of ~amd64. I only set 
the latter when this was a new box and too many packages needed to be the ~ 
versions to be manageable otherwise.

-- 
Regards,
Peter.

Re: [gentoo-user] Problem with gdbus-codegen

[Alan McKinnon]

On 26/01/2017 12:10, Peter Humphrey wrote:
> Hello list,
> 
> Today I have a block that I can't see a way out of.
> 
> [blocks B  ]  codegen-2.50.2" is blocking dev-libs/glib-2.50.2)
> [...]
>   (dev-util/gdbus-codegen-2.48.2:0/0::gentoo, ebuild scheduled for merge) 
> pulled in by
> dev-util/gdbus-codegen required by (gnome-base/dconf-0.26.0-
> r1:0/0::gentoo, installed)
> dev-util/gdbus-codegen required by (net-print/cups-
> filters-1.13.3:0/0::gentoo, installed)
> >=dev-util/gdbus-codegen-2.32 required by (sys-fs/
> udisks-2.1.8:2/2::gentoo, installed)
> >=dev-util/gdbus-codegen-2.48 required by (x11-libs/gtk
> +-3.22.5:3/3::gentoo, installed)
> dev-util/gdbus-codegen required by (sys-apps/
> accountsservice-0.6.43:0/0::gentoo, installed)
> 
> Then a lot of pages listing all the packages that want dev-libs/glib-2.50.2.
> 
> Grepping for util and libs under /etc/portage shows nothing, so I don't 
> think this is self-inflicted.
> 
> Before I go rushing off to b.g.o. (which doesn't have anything relevant 
> yet), am I the only one seeing this? I also have a slot conflict with x11-
> base/xorg-server and x11-drivers/xf86-video-amdgpu, but one thing at a time.
> 


gdbus-codegen-2.50.2 has been around since mid-Nov, so I can't see why
portage wants to give you 2.48.2.

Does explicitly emerging gdbus-codegen-2.50.2 then re-running a world
emerge give a different result?

-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Problem with gdbus-codegen

[Peter Humphrey]

Hello list,

Today I have a block that I can't see a way out of.

[blocks B  ] =dev-util/gdbus-codegen-2.32 required by (sys-fs/
udisks-2.1.8:2/2::gentoo, installed)
>=dev-util/gdbus-codegen-2.48 required by (x11-libs/gtk
+-3.22.5:3/3::gentoo, installed)
dev-util/gdbus-codegen required by (sys-apps/
accountsservice-0.6.43:0/0::gentoo, installed)

Then a lot of pages listing all the packages that want dev-libs/glib-2.50.2.

Grepping for util and libs under /etc/portage shows nothing, so I don't 
think this is self-inflicted.

Before I go rushing off to b.g.o. (which doesn't have anything relevant 
yet), am I the only one seeing this? I also have a slot conflict with x11-
base/xorg-server and x11-drivers/xf86-video-amdgpu, but one thing at a time.

-- 
Regards
Peter