[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.50.2 ("<dev-util/gdbus-
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.

--
Regards
Peter

[Alan McKinnon]

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.m...@gmail.com

[Peter Humphrey]

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

Alan McKinnon <alan.m...@gmail.com> 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.

[Dale]

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

:-) :-)

[Corbin Bird]

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

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

[Peter Humphrey]

Dale <rdale...@gmail.com> 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.

[Peter Humphrey]

Corbin Bird <corbi...@charter.net> 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.

[Neil Bothwick]

On Thu, 26 Jan 2017 17:15:04 +0000, 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.

[Alan McKinnon]

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.m...@gmail.com

[Dale]

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

:-) :-)

[Corbin Bird]

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 :)

[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

[Dale]

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

:-)  :-) 

[Marc Joliet]

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

[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

[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

[Daniel Frey]

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

Dan

[Peter Humphrey]

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

[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

[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

[Neil Bothwick]

On Sun, 29 Jan 2017 19:17:47 +0000, 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!

[Mick]

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

[Neil Bothwick]

On Sun, 29 Jan 2017 23:06:23 +0000, 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.

[Daniel Frey]

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

[Ian Zimmerman]

On 2017-01-29 09:59, Daniel Frey wrote:

> Before that I used anacron (I think it was anacron) which would run
> missed cronjobs.

Seriously OT:

Note that the gentoo implementation of /etc/cron.$FREQUENCY (unlike
others, for example debian's) takes care of this by itself. You don't
need anacron and you don't need any built-in anachronistic support in
the particular cron package, although some of them provide it.

Of course this assumes that you can use the $FREQUENCY mechanism instead
of a direct crontab entry.

--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

[Ian Zimmerman]

On 2017-01-29 22:10, Neil Bothwick wrote:

> 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.

OTOH, there is this recent news item:

https://www.phoronix.com/scan.php?page=news_item&px=Fedora26-Encrypted-TRIM-Discard

which made me add the discard option to my laptop's fstab (ext4).

[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

[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

[Alan McKinnon]

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.m...@gmail.com