So, I run into this problem a lot, and I'd like to put in a friendly request for portage (or equery?) to have a feature added to return the following information:

list of all package atoms updated/changed by emerge since [date]
last date [package atom] was updated/changed by emerge
"last date updated/changed" for dependencies returned by 'equery depgraph [package atom]'

See, I often run 'emerge -uD world' several times a week, and then discover that some random package isn't working. It's often a dependency that has broken (either at compile- or run-time), but I don't know which packages have been most recently updated. This would spare me getting the answer "just downgrade everything until the package works again" when I ask about it on the forum, and would help narrow down bug tracking as well. If I know a package worked last week, but not today, then I can be pretty safe in assuming that the problem lies only in packages that have been changed in between (obviously not always, but usually).

I suppose this would mean time-stamping emerge operations, but that might not be too difficult to implement?

Cheers,

EE
(who knows jack diddly about programming or anything, so is obviously being a dilettante)

First off, emerge does timestamp all merges, so that information is readily available, albiet, not easily human readable. You could however look at the modified date if you manually look through the /var/db/pkg/{cat}/{pkg-ver} entries.

Quote:

list of all package atoms updated/changed by emerge since [date]

I created enalyze in gentoolkit for full installed pkg db analysis. So, I could add that report to it.

Quote:

last date [package atom] was updated/changed by emerge
"last date updated/changed" for dependencies returned by 'equery depgraph [package atom]'

Yes it would be possible to add a new equery sub-module to show the time a pkg was last merged, or add that info to an existing one.
It should also be possible to add the merge time to the equery depgragh display.
One of the things we are intending is to add custom formatting output to all equery sub-modules, so if that information is made available, it could be specified in the output. Custom formatting is available in some modules currently, but the time info is not made available yet.

Please file a feature request "Enhancement" bug in bugzilla for these. We are starting to plan changes for gentoolkit-0.3.1
That way they won't be forgotten about._________________Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

ExecutorElassus ... 'date' is not always staightforward as there are many date formats, 2012-10-26, 26-10-12, 10-26-12, 10-26, Oct 26, 20121026, 26102012, etc, but a dated list of updates/changes can currently be aquired via 'qlop -lu' (app-portage/portage-utils), and there are methods of parsing the data provided, ie, for 'two days ago':

Doing something similar 'from date to current date' is possible, but the date format used would make it somewhat compilcated (at least for a oneliner). As dol-sen noted this information is availble in /var/db/pkg/ (qlop queries /varr/log/emerge.log I believe) so using this data would probably be a better solution.

ExecutorElassus wrote:

last date [package atom] was updated/changed by emerge

'eix' (app-portage/eix) provides this information in the 'Installed versions:' field.

Hmmm ... but depgraph lists dependencies (ie: based on 'use') whether these are installed or not, but ok, some clue as to installed/uninstalled deps might be useful.

ExecutorElassus wrote:

See, I often run 'emerge -uD world' several times a week, and then discover that some random package isn't working. It's often a dependency that has broken (either at compile- or run-time), but I don't know which packages have been most recently updated. This would spare me getting the answer "just downgrade everything until the package works again" when I ask about it on the forum, and would help narrow down bug tracking as well. If I know a package worked last week, but not today, then I can be pretty safe in assuming that the problem lies only in packages that have been changed in between (obviously not always, but usually).

Well, besides 'qlop -lu' you might want to read the section on PORTAGE_ELOG* in /usr/share/portage/config/make.conf.example.

eix and eix-sync shows you all the updates to the tree since last sync_________________A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.

You ask a question about queries that I seem to do about a dozen times per day for more years than I'd like to admit.

In order to cope with this insane amount of repetition, I've concocted a handful of script and aliases (a shorthand of sorts) as a survival mechanism. I'm certainly not the only one who's come up with a custom set (or framework) of utilities for Gentoo/Linux/Unix sysadmin, but this seems like a fine opportunity to post mine.
Note: I have not yet looked into elogv (thanks for the tip, @baaann); just merged it. I only hope that I don't regret posting my primitive methods of operation after trying it out...

So, here's what I do:

In general, I make use of /var/log/emerge.log for this information. ...but as you've probably seen, the time stamps are relatively-ugly and not-very-human-readable.

The date format is in epochs (seconds since 1/1/70). Converting it to human-readable is most-conveniently done in a stream; pipe the log file in and the results out to filter, a file, less, tee, whatever...

...or if you want to see a history of build performance, take a look at the history of complile times for whatever package you're interested in. Just grep for the start-of-compile and end-of-compile keywords in the log file (both coincidentally contain the string "Merging" with a trailing space:

...as for the last question, I'm rarely querying all outputs of a depgraph in one fell swoop. However, for reasons I cannot explain, I took a minute or two to slap something together. I can't vouch for its accuracy; just take it as a suggestion for a possible starting point. (WARNING: really ugly. Parental discretion is advised.)